[jira] [Updated] (TINKERPOP-3231) Optimize P.setValue() and P.getValue()

["Cole Greer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cole Greer updated TINKERPOP-3231:
----------------------------------
    Priority: Blocker  (was: Major)

> Optimize P.setValue() and P.getValue()
> --------------------------------------
>
>                 Key: TINKERPOP-3231
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-3231
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.8.0
>            Reporter: Cole Greer
>            Priority: Blocker
>
> First raised by Pieter Martin in discord: https://discord.com/channels/838910279550238720/893235809690464277/1470053903742537981
> The updated getValue and setValue methods in 3.8.0 result in excessive processing of collections for within/without predicates. This can be especially harmful with large collections (millions of literals). Some of this processing is necessary due to the needed separation between literals and GValues, however some of it can be improved.
> In the case of setValue(), it currently makes 2 complete passes through a collection, the first to check if GValues are present, and the second to split the list into literals and GValues. The intention of this 2 pass approach was to bypass the type sorting in the "no GValue" case, and retain the original collection type. This is likely unnecessary overhead which is unlikely to provide justifiable value. The sorting is necessary but can be achieved without this 2 pass approach.
> For getValue(), it is necessary to re-unify the literals and variables collections to retain the public interface of P. In the case where `this.variables` is empty, we could likely bypass the cloning step and directly return `this.literals`. There may be a concern with the method returning a clone of the collection in some circumstances, and the original collection in others. This warrants additional consideration, but perhaps is solvable by wrapping the result in `Collections.unmodifiableCollection()`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)