[squeak-dev] EndOfStream - cruft?

Bob Arning arning315 at comcast.net
Mon Jul 22 19:01:07 UTC 2013


Well, I dug around a bit more. Seems Andreas was concerned about 
performance, although I did not see an issue. A week later it was rolled 
back.

Also in question was the correct superclass for EndOfStream. I just made 
the change in a 4.2 image and TestRunner is not happy with it being an 
Error. Make it an Exception and that problem goes away.

Cheers,
Bob

5/24/00     Re: RE: EndOfStream an Error???

On Wed, 24 May 2000 01:32:44 -0700 "Raab, Andreas" 
<Andreas.Raab at disney.com> wrote:
 >As it is right now, we're paying the
 >price of an error recovery for something that happens quite often. 
There are
 >many places where senders of #next rely returning nil quickly if at 
the end
 >of the collection. Such as in #next:into:startingAt:, #nextChunk,
 >#nextDelimited:, #peekFor: etc. With the changes we have a slowdown of
 >approx. 500 for a simple test case like
 >
 >    | s |
 >    s _ ReadStream on: Array new.
 >    [1 to: 100000 do:[:i| s next]] timeToRun.
 >
 >While the slowdown is okay for an error recovery it is most definitely not
 >okay for those users who do in fact rely on the opposite - which is a 
quick
 >return of nil for a past end read operation. And as it stands ALL those
 >users are affected by the modification.

Andreas,

Do you have an example that's a little more realistic? I was wondering 
what the effect would be on typical code, so I made a change to count 
the number of times that EndOfStream was actually signalled. Then I 
browsed around for a while and when I checked the number, it was still 
zero! So, I thought, filing in some code ought to do it. Nope - still 
zero. It wasn't until I evaluated "(ReadStream on: '1') nextChunk" that 
I actually got a hit. Hmm...

Cheers,
Bob
======================
5/24/00    Re: RE: EndOfStream an Error???

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

==============================================



On 7/22/13 2:31 PM, Chris Muller wrote:
> Interesting, I wonder what the consequences were..
>
> On Mon, Jul 22, 2013 at 11:22 AM, Bob Arning <arning315 at comcast.net> wrote:
>> For the historically-obsessed,
>>
>> Change Set:        069EOS-hh (really2192EOS-hh)
>> Date:            18 May 2000
>> Author:            Helge Horch
>> Requires:        Squeak 2.8a
>>
>> Modifies ReadStream>>next to signal an Error (EndOfStream) on attempts to
>> read
>> at or beyond the end of the stream.  Thanks to Bob Arning (who is silently
>> credited
>> in the stamps <g>), existing applications relying on seeing nils should not
>> be
>> affected.
>>
>> Change Set:        102ReadStreamUndo-sma (really 2272ReadStreamUndo-sma)
>> Date:            1 June 2000
>> Author:            Stefan Matthias Aust
>>
>> Undo #2192. The consequences of raising an exception for EOF during
>> ReadStream>>next should be worked out in 2.9a but not for 2.8.
>>
>>
>> and, AFAIK, that was the end of that.
>>
>> Cheers,
>> Bob
>>
>> On 7/22/13 12:09 PM, Chris Muller wrote:
>>
>> What if a system needs to allow nil objects in a Stream of objects and
>> have it be treated as just another object in the stream rather than
>> the EOS marker?
>>
>> So, maybe ReadStream>>#next _should_ be signaling EndOfStream, so the
>> sender of #next can know the difference in that scenario.  Since the
>> defaultAction is ^nil, presumably we could simply change #next to do
>> that with no breakage...
>>
>> On Mon, Jul 22, 2013 at 9:02 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>
>> EndOfStream has no references in the base image. It claims to be used
>> by ReadStream >> #next, but that's not true.
>>
>> Time to die/deprecate?
>>
>> frank
>>
>>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130722/50d27820/attachment.htm


More information about the Squeak-dev mailing list