Subj : Re: Slow string conversion of long js functions
To   : Adrian Klein <master@dragosan.net>
From : Brendan Eich <brendan@meer.net>
Date : Sat Jan 10 2004 02:34 pm

Adrian Klein wrote:

> Hi all,
> 
> I occassionally found out that the conversion of javascript functions to 
> their String value in general seems to be very slow and not to scale to 
> well with the length of the function. I was just wondering if this could 
> be a useful hint for a future optimization and where it should be posted 
> if it should at all.
> 
> A Testsite, that performs the conversion of a relative long js function 
> to its String value 10 times (took about 3500 ms on a PII 450 with Win98 
> and Mozilla 1.5, whereas IE and Opera took only about 0 ms): 
> http://www.dragosan.net/slow_string.html
> 

That's because IE and Opera no doubt recover the function's source, 
saved or cached somewhere.  SpiderMonkey decompiles script bytecodes, 
with help from source notes, to prettyprint a canonical version of the 
function.  That is not an optimized path, nor should it be, AFAICT.

What real-world scenario requires this to be fast, or otherwise puts it 
on a critical path?

Let me guess: if you inadvertently call JS_ValueToString on any result 
of a script that you passed to JS_EvaluateScript (or one of its kin), 
then if the script ends in a function-valued expression, you'll find 
that you spend too much time in the decompiler.

If I have guessed right (based on Mozilla experience), the trick is to 
tell your embedding when to ignore script results, and when to bother 
converting them to strings.

If I've guessed wrong, please let me know what your use-case is. Thanks,

/be

.