kp gores wrote:
>
> at the end of this posting is some easy code i wrote to convert a file
> from one format to another.
>
> the file i read has about 70000 lines. during run of the convert function
> lisp (cmucl june 98 binaries) performs lots of garbage collections:
> [GC threshold exceeded with 2,007,152 bytes in use. Commencing GC.]
> [GC completed with 83,440 bytes retained and 1,923,712 bytes freed.]
> [GC will next occur when at least 2,083,440 bytes are in use.]
> ...
> , each freeing about 2mb.
> why is this code so inefficient? where do i waste so much space??
string-trim creates a copy of the string, as does subseq. So, you generate
at least 92 bytes for each line in copies of the string, which should be
about 7MB.
Then there is the princ/prin1 which are going to generate some amount of
garbage that is going to be implementation specific. I suspect this is
the source of more garbage than the string copies. You might try using
write-char, which I think is the most efficient portable method of writing,
and from looking at your code it should be relatively easy to do.
--
Christopher J. Vogt - Computer Consultant - Lisp, AI, Graphics, etc.
http://members.home.com/vogt/
In article <·················@computer.org>, ····@computer.org wrote:
> kp gores wrote:
> >
> > at the end of this posting is some easy code i wrote to convert a file
> > from one format to another.
> >
> > the file i read has about 70000 lines. during run of the convert function
> > lisp (cmucl june 98 binaries) performs lots of garbage collections:
> > [GC threshold exceeded with 2,007,152 bytes in use. Commencing GC.]
> > [GC completed with 83,440 bytes retained and 1,923,712 bytes freed.]
> > [GC will next occur when at least 2,083,440 bytes are in use.]
> > ...
> > , each freeing about 2mb.
> > why is this code so inefficient? where do i waste so much space??
>
> string-trim creates a copy of the string, as does subseq. So, you generate
> at least 92 bytes for each line in copies of the string, which should be
> about 7MB.
>
> Then there is the princ/prin1 which are going to generate some amount of
> garbage that is going to be implementation specific. I suspect this is
> the source of more garbage than the string copies. You might try using
> write-char, which I think is the most efficient portable method of writing,
> and from looking at your code it should be relatively easy to do.
He would need to tune the GC of CMU CL to some sane settings,
I guess. This would make GC not so painful.
How about the generational GC of a new CMU CL. Does it work
already? On which platforms?
>>>>> "Rainer" == Rainer Joswig <······@lavielle.com> writes:
Rainer> How about the generational GC of a new CMU CL. Does it work
Rainer> already? On which platforms?
I believe the generational GC is the default for Linux and FreeBSD for
the last few "releases". I don't think it's in the 18a release.
Generational GC exists only for the x86 platform. I'd like to try to
get it working on Solaris, but not yet.
Ray
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com (Rainer Joswig) writes:
> How about the generational GC of a new CMU CL. Does it work
> already? On which platforms?
In the cmucl-imp mailing list today, it was stated that the gengc is
available only on the x86 platforms and it has been the default for a year or
so.
Mike McDonald
·······@mikemac.com