This is the mail archive of the email@example.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]|
> I am coming to the conclusion that garbage collection won't work for > large databases. At least, you can't garbage collect them often > because there is so much data in the system that collection time > slows everything down. Would generational gc help? This sounds like the canonical case for it. > I feel that maybe within the database I sould be reference counting > and then copy the data out to a garbage collection environment on the > outside of the database. I would prefer to avoid needless copying but > copying is fast compared to scanning the whole database. If you know when your object are supposed to die, you can do some management yourself using dynamic-wind. This has been discussed recently over on comp.lang.lisp; you may want to check dejanews. Just some marginally related ideas... > The argument of ref counting against garbage collection is still largely > unsolved, and depends on the application. Personally, I think of refcounting as a simplistic gc strategy, so I don't see the two concept in conflict. There are tradeoffs, I agree to different gc strategies. > The difficult side of things is when you have a throw and catch > system that can figure out which variables fall out of scope and > thus which references to update. I have yet to see and elegant > solution to that problem. Yes. Exceptions and cycles make refcounting more difficult, and it's supposed simplicity benefits start to look suspect. "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken -russ -- If at first you don't succeed, don't try sky diving.