[Glass] Can/Should I use btreePlusIndex with Date element class?

[Dale Henrichs via Glass]

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 
> this:
>
> 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 
queries ...

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.
   GsIndexSpec new
     equalityIndex: 'date'
       lastElementClass: Date
       options:
         GsIndexOptions btreePlusIndex + GsIndexOptions optimizedComparison;
     createIndexesOn: nsc.
   nsc

It is possible to supply index options to the old-style index creation 
protocol by doing something like the following:

   | nsc |
   nsc := Bag new.
   nsc
     createEqualityIndexOn: 'data'
     withLastElementClass: Date
     options: GsIndexOptions btreePlusIndex + GsIndexOptions 
optimizedComparison.
   nsc

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

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171208/031336f3/attachment.html>