[racket] Is eval very slow?

It's fun growing older with computers. In the days of 8085's, we were almost happy to call a subroutine or switch contexts for an interrupt in 20 microseconds; my gosh, addresses and data must be pushed and popped and all of that stuff takes time.  The response earlier in this thread showed that an evaluation of a new expression, a much more considerable task, to be the same 20 microseconds... but these days we consider this to be intolerably slow. :O)

rac

On Jul 19, 2012, at 5:53 AM, Matthias Felleisen wrote:

> 
> Here is a conjecture at a history-based interpretation. 
> 
> Lisp was eval and apply, and that was all there was to it, and calling eval was dirt cheap -- compared to running code. 
> 
> Over the next few decades Lispers learned to "pre-process" Lisp, meaning a lot of dynamic computation was moved to pre-eval time. At the same time, Lispers learned that eval is evil in most cases and that it is often replacable by something simple (like a case dispatch on the op position plus apply). 
> 
> Other languages started being a "Lisp": perl, python, javascript. Instead of learning from Lisp's history, they re-invented it -- starting from a cheap eval cycle. Now eval is popular again. Perhaps this is even justified for initial uses of something like JavaScript. You send some code, it is eval'ed and the evaluation renders some "image" inside of a browser frame. Done. But now we do so much more with this interactive script -- manage mail, play games -- JavaScript needs to have a real compiler too. And as we get into compilation, its eval will get slower and perhaps JS programmers will re-learn what Lispers learned. 
> 
> But this won't be the end. I predict that in 20 years some other language will re-invent eval and it will resume from there. 
> 
> CS, the science of reinvention. 
> 
> 
> 
> 
> 
> On Jul 19, 2012, at 3:46 AM, Eli Barzilay wrote:
> 
>> Just now, John Clements wrote:
>>> 
>>> I don't think you should be shocked; I believe that calls to eval
>>> are essentially triggering full passes of the parser and compiler,
>>> dynamically. It's true that you could optimize for certain special
>>> cases (such as yours), but generally speaking these use cases are
>>> rare, particularly since I'm guessing that the places where this
>>> optimization would be possible are also the places where eval isn't
>>> needed.
>> 
>> As a sidenote, this is not something that is unique to racket or that
>> is new in any way...  I first "encountered" this in 1995 in a project
>> written in Allegro Lisp -- I was surprised about how slow `eval' was,
>> and when I asked about it, the advice I was given is that in extreme
>> cases where you really need a fast evaluation of dynamically generated
>> code, you're better off writing a mini-evaluator instead.
>> 
>> (Another sidenote: there are some languages with a "very fast" eval,
>> like elisp and newlisp.  In these languages it can be as fast as
>> running normal code, but this is because there is little to no
>> compilation done.)
>> 
>> -- 
>>         ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>                   http://barzilay.org/                   Maze is Life!
>> ____________________
>> Racket Users list:
>> http://lists.racket-lang.org/users
> 
> 
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users