Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!howland.reston.ans.net!newsfeed.internetmci.com!news.sprintlink.net!in1.uu.net!nntp.cadence.com!news
From: Nancy Aten <nancya@cadence.com>
Subject: VW2 #do:,#at: - array bounds checking? Opinions requested (repost)
Content-Type: text/plain; charset=us-ascii
Message-ID: <DE2ywL.HDF@Cadence.COM>
To: nancya@cadence.com
Sender: news@Cadence.COM
Content-Transfer-Encoding: 7bit
Organization: Cadence Design Systems, Inc.
References: <DE1yrs.6s8@Cadence.COM>
Mime-Version: 1.0
Date: Tue, 29 Aug 1995 16:24:20 GMT
X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3_U1 sun4m)
X-Url: news:DE1yrs.6s8@Cadence.COM
Lines: 56

I apologize for my incomplete email address in the first posting.
Should be corrected to nancya@cadence.com now.
 
------------original post-----------------------------------------
Some of our code spends unjustified amounts of time inside #at:, 
mostly as sent from within #do: methods on arrays. In VW2, 
SequenceableCollection implements #do: as follows.
 
do: aBlock
   1 to: self size do: [:i | aBlock value: (self at: i)].
 
The #at: method uses a primitive, which, ParcPlace tells me, does 
array bounds checking. ParcPlace says because of reasons of memory 
safety, they won't provide a non-bounds-checking version.
 
I won't try to argue here about allowing applications to choose the 
risk in performance-critical areas of tested code for #at:.
 
I'm merely asking for appropriate #do: methods to use a faster 
non-bounds-checking primitive, which would apparently be perfectly 
memory safe in this usage (since #do: is only walking valid indices). 
 
I'm trying to gather support to encourage ParcPlace to provide this 
presumably highly valuable and safe performance improvement. Please
help me with support, or by educating me on why this request is 
unreasonable. Thanks very much!
-----------end of original post------------------------------------
 
Thanks to Frank Adrian for the first reply by email. He raised good 
points, and so I want to add:
 
It would be acceptable to me short-term for ParcPlace to replace 
appropriate #do: methods directly with primitives, and avoid both
the bounds checking normally done in #at: and checking (e.g. number
of arguments) normally done in #value:. I.e. there'd be no new unsafe
additional versions of #at:. My understanding is ParcPlace doesn't 
want to do this either.
 
Ultimately (although I didn't want to go this far in my first opinion 
poll), I'd still argue for availability of the equivalent of #unsafeAt: 
and perhaps #unsafeValue:* methods. Anyone can write [primitive] code 
to make smalltalk core dump; the ParcPlace support problem raised by 
providing my methods is not a sufficient argument in my opinion (it's 
fine with me for core dumps to be unsupported if these methods are 
referenced in the code). In the case of optimized code performance vs. 
memory safety, I think it is reasonable to substitute "unsafe" optimized 
versions into performance-critical pieces of tested/released code. 
(Smalltalk doesn't have to be as fast as anything else to win, but it 
does need more reasonable solutions for performance-critical cpu-intensive 
code - "write that part in c" doesn't count, when that part is a heavy 
user of smalltalk data models). In my humble opinion.

Thanks.
Nancy Aten
nancya@cadence.com

