Subj : Re: Performance Interfacing to C++
To   : Thorsten R
From : Brendan Eich
Date : Fri Aug 27 2004 12:03 pm

Thorsten R wrote:

> This wouldn't make sense to me, because we
> instructed the engine that our code cares for getting and setting (and
> therefore storing and managing) the value of the property "nLeft".


You can use JSPROP_SHARED to avoid a value slot for such properties, but 
the engine will still build a hash table per object map (per object with 
its own properties, not one delegating all properties to its prototype), 
and those hash table entries will point into a global (per-runtime) 
lexicographic tree.

If you think this is too costly, I'd like to see profile data showing 
it.  I think you may be prematurely optimizing.

If you aren't, then you need to implement JSObjectOps.

> Especially for properties with long strings this would be a waste of memory
> and performance.

Strings require special handling even if you store references to them in 
your private (to the JS engine) data and do not use value slots (i.e., 
use JSPROP_SHARED as suggested above), if you want to avoid JS taking 
ownership of the malloc'd jschar array, or copying from your storage 
into its own.  See JS_AddExternalStringFinalizer and its comments in 
jsapi.h.

/be

.