[Glass] Can/Should I use btreePlusIndex with Date element class?
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Fri Dec 8 13:42:29 PST 2017
On 12/8/17 10:11 AM, Mariano Martinez Peck via Glass wrote:
> I have some equality index over a Date instVar. Right now created like
> collection createEqualityIndexOn: 'date' withLastElementClass: Date.
> Would I have a performance increase if I use btreePlusIndex?
Yes. Of course all performance answers have to come with a caveat:)
There are possibly some usage patterns for which you will see no
difference and some usage patterns where you will see improvements and
some where you may see some degradations ...
The performance improvements fall into two broad areas ... updates and
updates can see improvement because in legacy indexes there were
(potentially) two data structures that would be updated for each change:
the btree and the RcIndexDictioanry. In btree plus indexes we no longer
use the RcIndexDictionary so there are fewer objects involved in an
update ... there are some "corner" cases where an update can be more
expensive with Btree-plus indexes (by update in this specific case I am
referring to changing the value of an indexed instance variable) ---
this would show up in cases where there is low selectivity for the
indexed values (e.g. only a few possible values spread across 10's of
thousands of objects)
Queries can see improvements because the RCIndexDictionary is not used.
In legacy indexes every object in a query result has undergo a reverse
lookup through the RcINdexDictionary (of course there are exceptions:)
and the cost of the reverse lookup goes up with path length ...
The other way that queries show improvement is that objects may be
faulted into memory while creating the query result set when using
legacy indexes ... the btree plus indexes do not fault the objects into
memory when creating the result set ...
now if you are sending messages immediately to all of the objects in a
result set, this particular improvement might not be seen ...
There are additional dimensions where the btree plus indexes perform
better, but the real test is to see if your usage patterns benefit or
not ... if they are not beneficial I would encourage you to provide us
with a "simple" test case that illustrates your particular performance
issue and we will characterize the problem and see if we can come up
with a better solution ... eventually we are planning to deprecate the
legacy indexes, but to do that effectively, we really need feed back
from you guys to let us know about use cases where you are getting
poorer performance so we cna do the work necessary to provide equivalent
or better performance with the btree plush indexes
> If so, how could I create such an index for a Date? All the examples
> on the manual are about strings, symbols and unicode.
| nsc |
nsc := Bag new.
GsIndexOptions btreePlusIndex + GsIndexOptions optimizedComparison;
It is possible to supply index options to the old-style index creation
protocol by doing something like the following:
| nsc |
nsc := Bag new.
options: GsIndexOptions btreePlusIndex + GsIndexOptions
But I like to encourage the use of index specs, becausie it is not
always easy to provide enough flexibility using the old-style protocol
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glass