[pflanze]

> But it shouldn't be surprising that some languages are less efficient than others, right?

A long time ago I read a comment somewhere saying that Arc is interpreted (as in by a program itself written in MzScheme, instead of translated down to MzScheme), which struck me as odd but I didn't check back then, so now I finally went and looked through the Arc history[1] and release 0 already does the translation, so apparently that was just wrong. There can still be reasons why Arc could be slower, though, I remember PG's design called for overloading function calls so that e.g. hash table lookups could be written like function calls, and if implemented naively this could cost a slower than usual type check on each function call and prevent optimizations applied by the MzScheme/Racket compiler like perhaps function inlining. But just a different parsing infrastructure could explain it too (working on strings-as-vectors vs. lazy lists would make a large difference, but I couldn't get down far enough to see how that's implemented; srv.arc in parse-multipart-args uses regular expressions, not sure that's what you optimized?). Anyway, new code always has large potentials for optimization (early lisps were very slow, today's implementations are generally very fast; same was/is true for Java, JavaScript, ..).

[1] http://github.com/arclanguage/anarki