This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile Startup Time Suggestion



>  > A specific example of this is the lang parsing code, where it does
>  > indeed take something like this long (on my machine).  In fact, hobbit
>  > wouldn't help much at all here, since a large part of the time is
>  > spent initializing the regexp (the giant DFA) which is written in C.
> 
> Well, yes.  The two complement each other.
>  - hobbiting startup scheme code to make a library speeds up the code
>    itself & makes load time negligible, assuming the code doesn't do
>    any "work".
>  - Dumping would allow fast restarts of computations.

If the regexp state machine is constant then is there any reason why
hobbit cannot compile the initialised regexp data into the code. This is
pretty much what the flex utility does for C code. C programs have supported
the concept of compiling in initial variable values for quite some time.

> However, it's much easier to write specific dumpers for specific
> situations than to write a generic unexec.  In your particular case,
> why not write something to do a binary dump of the DFA to a file, &
> read it back in when you restart?  Pickling & unpickling specific
> data structures when you know their pointers is *much* easier than
> writing a generic unexec.

This is also a good point because you know how many pointers to expect
in your data and where to expect them. In theory the (write) procedure
can serialise any non recursive scheme data structure but in practice
this may not be useful for all situations.

	- Tel