murthy@cs.cornell.edu (Chet Murthy) (05/06/89)
I have an application that uses atoms as strings. That is, where another program would have used strings, this one uses atoms. It usually works OK because there isn't much string-manipulation going on. However, I just started doing major string manipulation, and I started running into major bottlenecks in intern-ing atoms. What happens is that every time I want to construct a string, say to print out, I have to build this atom, which has to be intern-ed, which means more stuff in the obarray (or whatever the per-package datastructure that contains stuff like that is called). Anyway, what I'd like to find out is what exactly happens inside Lucid common lisp when I execute the following code: (in-package 'user) (setq x 'foo) (unintern x) I assume that when the parser reads "foo", it interns "foo" into the current Package. "unintern" then removes that symbol from the package. Is it the case that the next time "foo" is read, a completely different symbol is allocated? is it the case that the old storage for the string "foo" will be reclaimed when "x" is set to a different value, after some garbage collection? I guess what I want to know is: If I intern a bunch of atoms, and then unintern, and drop all pointers to the atoms, will the storage used by those atoms ever be reclaimed? Look, I realize that this is just silly, and I should be doing this right, with strings instead of atoms, but I don't have that option, so I'm trying to work-around. Thanks in advance, --chet-- -- --chet-- murthy@svax.cs.cornell.edu --chet-- murthy@svax.cs.cornell.edu
bzs@bu-cs.bu.edu (Barry Shein) (05/11/89)
murthy@cs.cornell.edu (Chet Murthy): >Anyway, what I'd like to find out is what exactly happens inside Lucid >common lisp when I execute the following code: > >(in-package 'user) >(setq x 'foo) >(unintern x) > >I assume that when the parser reads "foo", it interns "foo" into the >current Package. "unintern" then removes that symbol from the package. Correct, easy enough to verify yourself using (DO-SYMBOLS), pp 187 of CLTL. >Is it the case that the next time "foo" is read, a completely different >symbol is allocated? If by "foo" you mean foo and not the string "foo" then yes, if you mean after the first foo was uninterned. If the old foo is still interned then of course it's re-used (ie. is EQ.) >is it the case that the old storage for the string "foo" will be reclaimed >when "x" is set to a different value, after some garbage collection? If there are no references to the old "foo" it should be reclaimed, there may be some caveats about this, you might call Lucid. Then again, perhaps I'm being confused by your use of the term "string", do you really mean print-name or atom? It makes a hell of a big difference when asking these questions. Strings can have slightly different rules than atoms in regards to storage reclamation. >I guess what I want to know is: If I intern a bunch of atoms, and then >unintern, and drop all pointers to the atoms, will the storage used by >those atoms ever be reclaimed? Yes, but most likely just put aside for re-use (ie. the memory will probably not be returned to Unix via a negative brk(), just put into a free atom pool for later re-use.) Does that make a difference? >Look, I realize that this is just silly, and I should be doing this >right, with strings instead of atoms, but I don't have that option, so >I'm trying to work-around. Here we agree, but there's also some sort of problem understanding exactly what you're trying to optimize and the real problem being solved. Not sure what "major bottlenecks" really means (it runs slowly? it doesn't run at all or crashes? it just seems wrong?) Also, compiling the code might cause different behavior than interpreting it as far as storage management of atoms is concerned, you might have to do some black-box experiments or ask someone at Lucid. -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.