pre-indexing an EventList for faster Filterator later

[Ted Zlatanov]

I often have a Filterator (user-side UI is a search text box) that looks
across 2K or more entries .  It would be nice if there was a way to
precompute the expected one-character and two-character searches
(letters+numbers+punctuation = about 50 and 250 possibilities
respectively) so when the user types that character the ListModel gets
updated instantaneously.

I know that these entries' search attributes will not change.  I'll call
set() on the original EventList if I need to recompute the index for the
entry.

Is that possible currently or do I need to write custom code (as I've
been doing, using bit vectors and nested maps)?

Thanks
Ted


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[James Lemieux]

Hey Ted,

   What you're looking for would require custom code.

   That said, how many search terms do each of the entries contribute through the filterator? As long as you're not doing a lot of String building just for the sake of the filterator (e.g. formatting dates, concatenating strings, etc) then 2K elements *, say 10 - 20 search terms per element should still probably be something that can be done in realtime, or near-realtime without resorting to indexing.

   If you are doing that kind of String building, try to cache the results in the objects you're querying.

James

2010/4/16 Ted Zlatanov <[hidden email]>

I often have a Filterator (user-side UI is a search text box) that looks
across 2K or more entries .  It would be nice if there was a way to
precompute the expected one-character and two-character searches
(letters+numbers+punctuation = about 50 and 250 possibilities
respectively) so when the user types that character the ListModel gets
updated instantaneously.

I know that these entries' search attributes will not change.  I'll call
set() on the original EventList if I need to recompute the index for the
entry.

Is that possible currently or do I need to write custom code (as I've
been doing, using bit vectors and nested maps)?

Thanks
Ted


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Ted Zlatanov]

On Fri, 16 Apr 2010 09:44:45 -0700 James Lemieux <[hidden email]> wrote:

JL>    That said, how many search terms do each of the entries contribute
JL> through the filterator? As long as you're not doing a lot of String building
JL> just for the sake of the filterator (e.g. formatting dates, concatenating
JL> strings, etc) then 2K elements *, say 10 - 20 search terms per element
JL> should still probably be something that can be done in realtime, or
JL> near-realtime without resorting to indexing.

JL>    If you are doing that kind of String building, try to cache the results
JL> in the objects you're querying.

I'll try precomputing the search results, thanks.  There are variable
parts so I'll schedule the reindexing of those on a background thread.

In theory searching 2K entries is fast, but often on a hosted VM the CPU
cycles are tight so my users have that awkward <100ms delay that makes
the UI experience less believable.  If precomputing doesn't help I'll
resort to custom code.

Thanks!
Ted


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]