[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 18:57:44 +0200

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:

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


  ()   Free GIS & Flash consultant/developer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]