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] |
> > 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