Can/Should I use btreePlusIndex with Date element class?

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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass