Path: utzoo!attcan!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Re: Problem requiring GC -- try again. Message-ID: <923@scaup.cl.cam.ac.uk> Date: 27 Sep 89 21:59:40 GMT References: <911@scaup.cl.cam.ac.uk> <8310@goofy.megatest.UUCP> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 56 Keywords: I wrote: >> Here are some problems where programmer-controlled storage management >> would be very difficult or impossible. >> >> Interactive editting of cyclic graph data structures. You have a >> heterogeneous cyclic graph data structure and the editor must be able >> to make arbitrary sequences of changes to the data structure. How >> do you detect that a subgraph has become detached? Dave Jones replied: > Funny you should ask, because I'm working on such a problem even as we > speak, sans garbage-collector. The editor is not interactive -- it is > essentially an optimizer which reduces graphs by calculating equivalency > classes of subgraphs -- but I don't see that that matters much whether it > is interactive or not. I handled the sitch by making an "arrow" a proper > data-object, not just a vanilla pointer. One extra pointer's worth of > memory per arrow, but cheap at twice the price! First: you are solving a special case of a graph consisting of nodes connected by two way links. I was thinking of the more general case (harder) problem where the links are ordinary pointers. Try to imagine a randomly connected network of records of various types with pointers going all over the place. The problem is to construct a graph editor that will allow me to make modifications to this data structure in place. It might be part of an interactive debugger, or a tool for patching a knowledge base or something like that. Second: have you tried measuring the performance of your non-GC'ed solution to your problem against that of an equivalent GC'ed solution (same problem, same language/compiler, decent garbage collector ...) Without taking proper measurements, your pronouncements about the efficiency advantages of your solution have no scientific basis. Even then, the special nature of the graphs you are dealing with and the calculations your program does tends to make performance generalisations. Third: I presume that you realise that with your data structures, adding and deleting an arrow both have complexity order (M + N) where M and N are the average number of in arrows and out arrows respectively per node. You are trading off reclamation overheads against the overheads of constructing and mutating the data structure. (Of course there may be other application specific reasons for using your data structures ... but that is not at issue) Finally: you must admit that even your special case solution was hard to arrive at, and that at least the storage management aspects would have been considerably easier if you had a GC in your language. > (A wise man once said, if you don't understand the problem well > enough to know when an object is unreachable, you don't understand > the problem well enough.) That sounds more like the pronouncement of a fool to me ... -- Steve