On Wed, 24 May 2000 12:32:32 -0700 "Raab, Andreas" <Andreas.Raab at disney.com> wrote:
>What I do know, however, is that not too long ago we've integrated a change
>set (I think from Bert) which modified quite some places to use the
>#next/#isNil test instead of #atEnd. Which leads me to the assumption that
>there ought to be places in which a quick return might be really critical.

I think there is an important distinction here. If you have code like:

[s atEnd] whileFalse: [el _ s next. el whatEver]

then you will be sending #atEnd for each element in the stream and sending #next one less time. By changing that to

[(el _ s next) isNil] whileFalse: [el whatEver]

you are essentially substituting #isNil for #atEnd for every element. That can add up to substantial savings. The change to EndOfStream changes only the performance of the *last* #next while all the others (assuming there are elements in the stream) remain as fast as ever. There will clearly be some performance penalty, but the magnitude will depend on the number of elements processed before end of stream. If the typical case involves empty streams, then the cost will be quite high. If the typical stream processed as above has tens or hundreds (or more) of elements, then the cost of EndOfStream will be a much smaller fraction of the total processing time.

I think, as has already been suggested, it might be wise to back off this change until we resolve whether Error or Exception is a better place for it (I lean toward Exception, Notification or perhaps ErrorsForWhichTheDefaultActionIsUsuallyAcceptable rather than Error). Once that is decided, we can see if there are any noticeable performance hits, especially once EndOfStream is added to the other places where it can be detected (StandardFileStream>>next, e.g.).

Cheers,
Bob