Yes to all of this. I'll revert my change and start over with a
hashtable-driven approach.
jim
On Apr 4, 2006, at 11:49 AM, Oliver Steele wrote:
> I sent some code to this list last week that might be useful for
> this. It contained a version of _lookups with all the properties
> referenced in these functions, and some of the changes necessary to
> use this lookup table.
>
> Jim measured this and, to my surprise, it wasn't faster on Flash.
> I guess the moral of this is that it's worth measuring whether the
> change actually improves performance on some specific runtime,
> rather than assuming that it might.
>
> However, there's an additional complexity that I just thought of.
> The full cost of string construction might not show up in a
> profiler because part of the cost is the increased object churn,
> which dials up the gc frequency, and a profiling run wouldn't show
> this unless it was long enough to trigger a statistically accurate
> number gcs. So a table-driven approach, which substitutes the cost
> of hashing for the cost of string construction, might still be
> faster over the long term even if it measures out the same in a
> short run, by replacing string allocation (pay not AND pay later)
> with hash lookup (pay only now).
>
> On Apr 4, 2006, at 1:50 PM, Adam Wolff wrote:
>
>> On Apr 4, Jim Grandy wrote:
>> [snip]
>>> Since hash lookup ought to be cheap on any reasonable JS runtime, I
>>> could back off to consolidated routines that look up symbols in a
>>> hash,
>>> rather than completely split routines.
>> I think this is the right thing to do.
>>
>> Some static hashes on view of this sort:
>>
>> LzView.prototype._lookups = { axes : { x : "width" , y :
>> "height" },
>> resource : { width : "resourcewidth" ,
>> height:
>> "resourceheight" },
>> stretch : { width :
>> "unstretchedwidth" ,
>> height:
>> "unstretchedheight" },
>> ....
>>
>> would be generally useful.
>>
>> A
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>