JS_Enumerate does a js::GetPropertyNames, then converts that AutoIdArray into a JSIdArray, which involves an extra heap allocation. May not always be big, but it's easily-avoided waste, it needlessly cruftifies the code and executed code with another layer of conversion, and (most importantly in my view) you lose bounds-checking assertion goodness. (There might be a use case for JS_Enumerate in internal code, but in the common cases, I don't immediately see how it's necessary.) This was motivated by jsobj.cpp:DefineProperties, which, prior to the changeset that introduced proxies, properly used js::GetPropertyNames to get own property names. Just brainstorming, but is there some way -- if indeed JS_Enumerate has no good uses internally -- that we could blacklist it and prevent it from being usable? Maybe a #define JS_Enumerate(cx, obj) USE_GETPROPERTYNAMES_INSTEAD in some central location?
We could use some #ifdef'ery -- we have similar for Value vs. jsval, Class vs. JSClass, right? This is a good bug. It's an extreme case of a general rule that could use some automated enforcing: avoid going through JS_* APIs from within the engine. /be
You need to log in before you can comment on or make changes to this bug.