[Vm-dev] Bug in Interpreter>>primitiveNextPut:

[Eliot Miranda]

On Thu, Nov 26, 2009 at 8:43 AM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> I opened a Mantis bug report for this issue:
>
>  http://bugs.squeak.org/view.php?id=7421
>
> Dave
>

I wouldn't bother trying to fix the primitive.  Both in VisualWorks and at
Teleplace the experience has been the same, getting rid of the primitives
for next, nextPut: and atEnd sped things up.  The system is simply too
complex nowadays for these primitives to pay for themselves because they
only cover a small number of cases.  The primitives support Array and
ByteString bow there are so many different kinds of arrays being streamed
over that the cost of primitive failures outweigh the benefits of primitive
successes.


> On Thu, Nov 26, 2009 at 03:10:52PM +0100, Henrik Johansen wrote:
> >
> > Interpreter >> primitiveNextPut:
> >  limit := self fetchInteger: StreamReadLimitIndex ofObject: stream.
> >       atIx := (array bitAnd: AtCacheMask) + AtPutBase.
> >       (index < limit and: [(atCache at: atIx+AtCacheOop) = array])
> >
> > so basically, it needs ReadLimit to be > 0. (Which is only true for
> (Read)WriteStreams if created with on:from:to:).
> >
> > Changing the first line to
> >  limit := self fetchInteger: StreamWriteLimitIndex ofObject: stream.
> >
> > and the primitive now works.
> > ws := WriteStream on: (String new: 500000).
> > [1 to: 500000 do: [:ix | ws nextPut: $a]] timeToRun
> >
> > before: 130
> >  after: 33
> >
> > Inserted a counter after the prim call, for the loop above it was always
> >= 500000, with fix it's >=1.
> >
> > Cheers,
> > Henry
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20091126/58c7303e/attachment-0001.htm