

John Resig on TraceMonkey - sant0sk1
http://ejohn.org/blog/tracemonkey/

======
invisible
I think the key point of this article over the other related article
(<http://news.ycombinator.com/item?id=284192>) is that John points out that
tracing will be able to be applied to DOM manipulation/property access in the
future.

    
    
      "Being able to trace through a DOM method would successfully speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation and property access."
    

As I said on the previous article, "I believe tracing very well could be the
key to unlocking advances in that [DOM] area as well."

To me, this means that JavaScript will finally be integrated with the browser
in a way that is required to advance the web. I've always wondered what would
be the "big thing" to lead up to the move towards the web even more, and this
is definitely the answer.

The only thing left now is making it so JavaScript can be compiled (the only
way I can think of how to accomplish preventing stealing code).

~~~
gruseom
_speed up, not only, math and object-intensive applications (as it does now)
but also regular DOM manipulation_

Agreed. The sooner they get to that, the better!

Edit: As an aside, the web arguably wouldn't have happened without "stealing
code". I see this as a strength not a weakness.

~~~
invisible
I'm not against open sourcing code, or giving away helpful small things, but
at the moment anyone can copy every bit of useful functionality of a JS
application and just create their own back-end. That is a very ridiculous
concept, and there isn't much that can be done about it if that person isn't
within the same country.

~~~
thwarted
It might be more valuable to avoid basing your business on artificial scarcity
to begin with.

~~~
invisible
Well, I guess if the business model were to not make a significant amount of
money then no scarcity would be perfect! But really, scarcity (real or "fake")
needs to exist or else I would be wasting time creating a PRODUCT (in other
words: something that is sold).

~~~
ph0rque
> scarcity (real or "fake") needs to exist or else I would be wasting time
> creating a PRODUCT (in other words: something that is sold).

Not true: see 37signals, for example.

~~~
invisible
I think you misunderstand what artificial scarcity means (or I do somehow).
37signals is proof that artificial scarcity must exist in some form to profit.
Adding a price to something creates a form of artificial scarcity. From my
perspective, you just agreed with me.

~~~
thwarted
Artificial scarcity is trying to limit access to something which can not be
limited. Once bits, for any purpose, are put in the right order to do
something or represent something, the cost to replicate those bits to other
parties is zero. In contrast with an automobile, even after it is designed,
significant infrastructure (currently) needs to be built and exist to create
another one. What you are paying for when you purchase a car is the PROCESS
that went into creating JUST that ONE car you bought. Additional cars would
not exist if the infrastructure didn't exist to create more of them (and then
economies of scale come into play, making the car actually affordable). Bits
do not have that limitation.

Scarcity and want must exist in order to set a legitimate price. Artificial
scarcity sets a price on something that isn't actually scarce. It is a
(unfortunate?) side-effect of the market that potential buyers think that
because something has a price, it must be worth having (ie scarce). I don't
think there's actually anything wrong with basing a business on this, but
don't be surprised when your customers realize you've been selling them
something that should have a price closer to zero because there is infinite
supply.

------
KirinDave
Has anyone run a comparison between this new engine and SquirrelFish yet? It
seems to me like two major ideas are competing:

1\. Better JIT for interpreters. 2\. Faster interpreters, period.

I'm really curious to see which has the faster ramp-up and which has the best
end-game results.

~~~
jeresig
One comparison was posted in the comments of the blog post:
[http://www.masonchang.com/2008/08/tracemonkey-vs-
squirrelfis...](http://www.masonchang.com/2008/08/tracemonkey-vs-
squirrelfish.html)

------
sh1mmer
John does a really job of discussion what implications this had as well as how
it does it. Great article.

------
tokipin
check out Steve Yegge's video/transcript about dynamic language optimization
in case you missed it:

[http://steve-yegge.blogspot.com/2008/05/dynamic-languages-
st...](http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-
back.html)

~~~
andreyf
Things have been moving in this direction for quite some time, I think. Here's
a master's thesis from March 2006:

<http://www.cs.wustl.edu/~plezbert/contcom/>

~~~
MaysonL
Michael Franz, the PI for the work at UCI, has been working on this stuff for
almost 20 years. See his 1994 PHD thesis: _Code-Generation On-the-Fly_
ftp://ftp.inf.ethz.ch/pub/publications/diss/th10497.ps [postscript]. Reading
it was one of my "Holy Shit!" moments.

------
nostrademons
It's funny, 2 months after I give up on GameClay (partially because of
performance issues in the prototypes), this comes out. Maybe I should go back
to it. Well, that's why I chose not to open-source the code and my cofounder's
hanging on to the domain names.

Though any application to games needs to get over the fact that 90% of the
casual game market still uses IE...

------
ivankirigin
Install the update and do the image manipulation test. For best results, run
the test before and after. The difference is astounding.

~~~
babyshake
I thought "astounding" would be an overstatement. Turns out you're right.

