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

[Mariano Martinez Peck via Glass]

On Fri, Dec 8, 2017 at 6:42 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

>
>
> 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
>


Thanks for the detailed explanation.


> 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
>
>

Thanks, yes, I have migrated my indexes construction code to use the new
GsIndexSpec now. Good idea, long overdue for me.

Cheers,



> Dale
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171211/4c9dedd6/attachment.html>