Yes, thank you, this is a good idea to restore lazy initialization.
Current strategy is strange.
Reading current code, I wonder if the intention was to make an access 
(self noCheckAt: size + 1) fail when (size \\ chunkSize ~= 0) ?
but this should already be handled by pvtCheckIndex: ...


Note that using \\ is preferable for code readability, but not for 
performance if you use LargeInteger:

| int32 q r |
int32 := 1 << 31.
{
	[q := int32 - 1 // 1024 + 1.
	r := int32 - 1 \\ 1024 + 1] bench.

	[q := int32 - 1 // 1024 + 1.
	r := int32 - 1 - (q-1*1024) + 1] bench.
}.

#('30482.50349930014 per second.'
  '42663.0673865227 per second.')

Yes because, primitive 31 fails and super revert to the second form 
which was inlined in SparseLargeTable...

Sure this does not really matter, I doubt this access be the bottleneck 
of any code, and maybe you already hacked primitive 31...

Nicolas


Eliot Miranda a écrit :
> 
> 
> On Sat, Nov 1, 2008 at 2:49 PM, Yoshiki Ohshima <yoshiki at vpri.org 
> <mailto:yoshiki at vpri.org>> wrote:
> 
>     At Sat, 1 Nov 2008 12:12:21 -0700,
>     Eliot Miranda wrote:
>      >
>      > [1  <multipart/alternative (7bit)>]
>      > [1.1  <text/plain; ISO-8859-1 (7bit)>]
>      >
>      > [1.2  <text/html; ISO-8859-1 (7bit)>]
>      > Hi All,
>      >
>      >     SparseLargeTable appears not to be sparse at all.  If you
>     look at SparseLargeTable>>
>      > initChunkSize:size:arrayClass:base:defaultValue: you'll see tat
>     each bin is initialized with an instance of the base
>      > class rather than being filled lazily.  Further, instead of
>     pvtNoCheckAt:put: lazily creating an entry in each bin as
>      > needed it simply throws away the write if the bin is empty.
>      Instead the usage pattern is to create fully-populated
>      > instances and then make them sparse by sending zapDefaultOnlyEntries.
> 
>      Correct.  As you saw, it is designed for the usage pattern of
>     creating a read-only table once.
> 
>      > It seems to me that
>     SparseLargeTable>>initChunkSize:size:arrayClass:base:defaultValue:
>     should leave bins empty
>      > until pvtNoCheckAt:put: puts other than the default value.  Since
>     I want to create a sparse table with 2^32 entries the
>      > existing approach won't work.
> 
>      Ah ha.
> 
>      > I wondered whether anyone else had already fixed this or whether
>     there's a good reason not to lazily initialize.
> 
>      I'm not aware of anybody who fixed.  Well, if you need to hold 2^32
>     entries, you should do whatever it takes and doing the lazy
>     initialization seems to be good...
> 
> 
> Here's what I came up with.  Note the use of \\ in noCheckAt:[put:] 
> which avoids an extra arithmetic op (a multiplication).  You might 
> consider replacing the relevant parts of SparseLargeTable with this as I 
> don't see the utility of filling the bins eagerly.
> 
>  
> 
> 
> 
>     -- Yoshiki
> 
> 
> 
> ------------------------------------------------------------------------
> 
>