patch to improve startup time on low end hardware

[Remco van 't Veer]

Hi Rich,

I've been working on getting clojure in a more usable state for android
[1]. One of the challenges was to speedup startup time. A lot of
time is spend in the lisp-reader because all constants are stored as
lisp expressions. I've replace most of this code by a more direct
approach; emitting calls to Symbol.intern, RT.var, RT.vector etc.
These changes make loading core about 3 to 4 times faster.

Are you interested in this patch? Should I open an issue on the
project site?

Regards,
Remco


[1] http://github.com/remvee/clojure/

[Rich Hickey]

On Feb 10, 3:47 am, "Remco van 't Veer" <rwvtv...@gmail.com> wrote:
> Hi Rich,
>
> I've been working on getting clojure in a more usable state for android
> [1]. One of the challenges was to speedup startup time. A lot of
> time is spend in the lisp-reader because all constants are stored as
> lisp expressions. I've replace most of this code by a more direct
> approach; emitting calls to Symbol.intern, RT.var, RT.vector etc.
> These changes make loading core about 3 to 4 times faster.
>

I am interested in this. The current constant serialization is just
the simplest thing to do, and had added utility for any text-based
transfer. I held off on binary/bytecode serialization because I hadn't
yet decided how to make that extensible. I guess it's not the worst
thing if the set of frequently used known types gets special handling
with the print-dup fallback.

> Are you interested in this patch? Should I open an issue on the
> project site?
>

Sure, thanks. It's important that the mechanism preserve the actual
types, so sections like this bit (in emitValue):

if (value instanceof List)

still need refinement.

Rich

[Remco van 't Veer]

I'll work on preserving the exact type for the common cases and will
open an issue with patch when I got it working.

Remco

[Remco van 't Veer]

Working on this I noticed a lot of meta data is discarded by to
current, serialize everything to lisp expressions, code when compiling
core.clj. This happens because the constants are emitted while core
is loaded and the writer depends on core-print which does write meta
data for a couple of types.

Isn't this a problem? Rich can you confirm? Or should the constants
in AOT compiled code not contain meta data at all? Seems very
unlikely! If it doesn't need meta data, why not?

Emitting meta data properly might even allow one to get rid of
*print-initialized* which seems hackish to me.

Remco

[Rich Hickey]

On Feb 11, 4:36 am, "Remco van 't Veer" <rwvtv...@gmail.com> wrote:
> On Tue, Feb 10, 2009 at 1:57 PM, Remco van 't Veer <rwvtv...@gmail.com> wrote:

Yes, there are gaps in metadata retention, and *print-initialized* is
definitely a bootstrap thing I'd love to lose.

Rich

[Remco van 't Veer]

Created issued including patch:

http://code.google.com/p/clojure/issues/detail?id=78

The CA is in the mail.