[thelist] JavaScript traps - need input for article

Liorean Liorean at user.bip.net
Thu Oct 10 19:28:01 CDT 2002


At 14:44 2002-10-09 -0400, Peter Barrett wrote:
>Hm. I don't suppose this counts as an expert tip, but I'm interested in
>what wisdom others on the list have to pass on, so I'll try a couple to
>start the ball rolling:

Good initiative. I fear it didn't catch on, though.

>         1. Simplicity. JS developers worry about character count (code
> size), and runtime evaluation as performance killers.

Actually, often slightly larger code can increase performance. Always using
the semi-colon for statement terminator is one such thing, or at least was
in the dasys of earlier, less optimised JavaScript engines.

The developers rather worry about two things. Loading time, where size
matters, and running time, where performance matters.

BTW, lovely example of what not to do you had there. I'll save it in my
quotes file...

>         2. Functions are Data. While this principle can be used to easily
> create tons of impossible-to-maintain self-modifying code, this principle
> also allows for reflection (via the for/in loop, or closer to the metal,
> inspecting the actual string that defines a function) and, as I
> discovered, a great way to add metrics gathering.
>
>         For example, when asked to improve the performance of the JS
> framework that I'm maintaining, I wrote a small module that, at runtime,
> gathers up all of the user-defined functions, and redefines them with
> calls to logging facilities to each function. One sweep of use (very
> slow, of course), and you have metrics on which functions are called most
> often, when, *relative* timing (not as good as absolute, as allthose
> debug calls throw it off, but still useful), return values, etc.
>         This is a pretty neat feature, because I don't need to add all of
> those debug statements by hand (~10K lines of JavaScript in total on this
> site/webservice), which would need to come out before deployment anyway.
> Sure it runs terribly slowly, but it's for debug, so who cares? Now I can
> just include the file with other JS on any page I want to test... No
> maintaining any extra script. I found a few bottlenecks I hadn't
> suspected, I don't have to maintain the modified code - it gets tossed
> each time, and it's useful to any JS package that my team writes in the
> future. Some of the best code re-use I've ever gotten.

Actually you go over my head with this. Would you care to explain more in
detail what it does, so that I might understand the brilliance of it?

// Liorean




More information about the thelist mailing list