[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: string_table::noCase
From: |
strk |
Subject: |
Re: [Gnash-dev] Re: string_table::noCase |
Date: |
Thu, 5 Aug 2010 19:01:04 +0200 |
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