On Tue, Sep 20, 2005 at 12:15:15AM -0700, Ross Boylan wrote:
> One follow-up question:
> ...
> > David T. Lewis wrote:
> ...
> > >The problem I saw was that #scanFor: degraded horribly when there
> > >were a lot of entries in the WeakRegistry. In normal Squeak usage,
> > >this did not happen, but in my case I was accidentally accumulating
> > >a lot of entries in the registry (*).
> ...
> > >(*) Specifically, I was using a subclass of StandardFileStream to
> > >represent the end points of an operating system pipe; then I made
> > >and destroyed large numbers of these in the course of making command
> > >pipelines (see CommandShell on SqueakMap). After running a large
> > >number of SUnit tests, these things would accumulate in the registry
> > >to the point where performance degraded horribly. Once I found the
> > >culprit, I just quit registering the pipe endpoints (which of course
> > >are transient things that don't need to be registered), and my
> > >"CPU problem" went away.
> 
> Was this registration something you did explicitly, or did it happen
> behind the scenes?  Or perhaps I'm not understanding what you mean by
> register.  The "registration" that I'm doing, that I'm aware of, is
> registering dependents.  I think I'm using a mix of the old and new
> systems for doing so (when:send:to: and update/changed).  I suspect
> you mean something else.

It was explicit, as opposed to something done with when:send:to: or
update/changed. This is just the normal behavior of StandardFileStream
(StandardFileStream class>>register). In OSProcess and CommandShell
it is easy to create and destroy lots of AttachableFileStreams
as OS pipes are opened and closed, and these get registered in the
WeakRegistry of class StandardFileStream.

This does not cause a noticable performance problem most of the
time, but if I recall right I had a bug in my code in which I was
failing to close some pipe connections. After these started to
accumulate in the registry, performance degraded badly. I don't
remember for sure, but I think it took only a relatively small
number of entries (perhaps hundreds, not thousands) for this to
be a problem.

I'm telling you this from memory, and it happened a few years
ago, so you should not trust the details of what I'm saying.
But if you have some collections like this that contain thousands
of entries, you may be encountering a similar issue.

Dave