Re: [Gnash-dev] Re: string_table::noCase

[strk]

If you're interested, profile for winterbell is here:
http://strk.keybit.net/tmp/profile.bells.gz

Check the call graph for ::noCase (top-most time-consuming function)

--strk;

On Thu, Aug 05, 2010 at 06:57:44PM +0200, strk wrote:
> On Sat, Jul 31, 2010 at 03:22:09PM +0200, Benjamin Wolsey wrote:
> > > The call to noCase seek for a match in a table of caseful-to-caseless
> > > string_table::key values (longs) in order to tell if the input is already
> > > lower-case or not (can Ben confirm this?).
> > 
> > The string table design means that unique strings are represented by
> > arbitrary keys. This obviously means that, given two keys, there's no
> > way to tell if they are equal case-insensitively.
> > 
> > That was the problem that the second lookup table solved. It means that
> > the 'case-insensitive' version of each string has its own key, and that
> > all strings that match the case-insensitive version can be matched to
> > that key.
> 
> What about caching the case-insensitive version of each key ?
> That could mean typedef'ing string_table::key to a pair of longs...
> 
> > Objects have a container of properties with three indices:
> > 
> > a) Sequenced (creation order). This is the only necessary order for
> > compatible behaviour.
> > b) Case-sensitive. This improves lookup speed for large containers like
> > arrays.
> > c) Case-insensitive. This improves lookup speed for SWF6 and below.
> 
> I see these ones:
>             boost::multi_index::sequenced<>,
>             boost::multi_index::ordered_unique<NameExtractor>,
>             boost::multi_index::ordered_non_unique<KeyExtractor>
> 
> You mean the KeyExtractor index is _only_ for case-insensitive keys ?
> 
> > > Was this tested to be faster than looking for the string directly
> > > using a case-insensitive index ?
> > 
> > I'm not sure where exactly you would do this if it's not covered by one
> > of the options above.
> 
> I mean by dropping the use of string_table, but ofc that's a huge
> change, and not necessarely faster. Should probably add some stats
> support in PropertyList to figure out which are the most commonly
> looked up keys as this specific profile suggests it's __proto__
> (already lower-cased, btw, so will trigger worst case in _caseTable
> lookup).
> 
> --strk;
> 
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html