[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More file output performance
- To: firstname.lastname@example.org (Karsten Poeck)
- Subject: Re: More file output performance
- From: email@example.com (Doug Currie, Flavors Technology, Inc.)
- Date: Fri, 14 Jan 1994 15:36:03 -0500
- Cc: firstname.lastname@example.org
>And really, when I dont write anything on the hard-disk and only execute
>(format nil "(setf (symbol-plist '~a) ~S)~%" symbol (symbol-plist symbol))
>to generate the strings it takes about 35 seconds and when
>I omit the format and save a constant string it only takes 8 seconds.
>So the given the string is fast enough, so
>the problem is not the LISP-MAC-IO in itself.
>I have absolutely no idea have I could speed up the stuff and would
>extremly appreciate any hints.
What you need is a "fasdumper" and "fasloader." This is what you get for
free when you use the "#., compile file trick." I don't know if Apple is
willing to (or has already) let us in on the details of using the internal
fasdumper. The benefits of using it are that there is no conversion of LISP
data to/from ASCII text form, the data is dumped in binary format using
highly optimized code.
Flavors has developed a LISP fasdumper/fasloader in conjunction with
Graphael (France). Unfortunately, the license agreement between us does not
permit me to give you the fasdumper/fasloader. There may be other OODB
vendors who can unbundle a fasdumper/fasloader from their product; perhaps
Itasksa is one. Have you looked at how Wood (MCL 2.0 CD-ROM) does it? (I
You may find that you could benefit from other aspects of an OODB as well.
If so, you may like to join the few of us who are anxiously waiting for
MCL's support of lightweight threads (e.g., stack groups) so Itaska (and
others?) can do a port to MCL.
As a last resort you could write your own fasdumper/fasloader. It is a
chore, but if you are dumping a limited number of types, and no circular
structures, is pretty straightforward. Doing your own data buffering and
using native Mac file io calls are big wins. In my opinion a CLOS interface
and model based on make-load-form-saving-slots will put you in the best
position to take advantage of persistent CLOS OODBs when such things are
finally available on the Mac.
If you need help getting started, let me know. Perhaps I can sketch out the
structure of a fasdumper and fasloader and relay some non-proprietary