Related articles |
---|
Bison, memory leaking md3den@mdstud.chalmers.se (Dennis Bj|rklund) (1997-05-25) |
Re: Bison, memory leaking cef@geodesic.com (Charles Fiterman) (1997-05-27) |
Re: Bison, memory leaking pfox@lehman.com (Paul David Fox) (1997-05-27) |
Re: Bison, memory leaking md3den@mdstud.chalmers.se (1997-06-02) |
Re: Bison, memory leaking sam.ravnborg@image.dk (1997-06-04) |
From: | Paul David Fox <pfox@lehman.com> |
Newsgroups: | comp.compilers |
Date: | 27 May 1997 23:48:53 -0400 |
Organization: | None in particular |
References: | 97-05-274 |
Keywords: | parse, storage |
Dennis Bj|rklund wrote:
>
> There is a problem with bison. When bison tries to fix a parse error
> then it discards semantic values on the valuestack and it discards
> tokens that it gets from yylex(), until it reaches a state that it can
> reduce in.
>
> [This is a well-known yacc problem. I usually solve it by chaining the
> malloc'ed data together and then releasing it all either at the end of
> the parse or in the top-level statement-list type rule. -John]
I can second that (John's reply). For a large parse-tree, the overhead
of malloc() can be extremely high. Not only that but you can
half your performance by trying to free the memory afterwards.
You can gain oodles of speedups by having your own fixed-size mallocator
and freeing things in huge chunks. Not only that - this effectively
gives you a form of garbage collection for free.
| Paul David Fox Lehman Brothers. |
| Consulant E-mail: pfox@lehman.com |
| #### Sold! ########### Home: fox@crisp.demon.co.uk |
| ###################### Tel: +44 171 601 0011 x6025 |
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.