<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-27 4:30 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The issue actually relates purely to Squeak domain models. Consider<br>
the case of an all-in-memory object model in Squeak, with no database<br>
involved at all. It is very feasible an app would want to import a<br>
flat-file dataset that involves creation a few million DateAndTime<br>
instances (along with other objects, of course) to the point where<br>
memory constraints begin to be noticed.<br>
<br>
When dealing with this level of prolifigation-potential of a<br>
particular class, and for such a base data-type we don't want to<br>
endure changing again, I want us to strongly scrutinize the internal<br>
representation.<br>
<br>
In this case, the use of 'utcMicroseconds' introduces a lot of<br>
duplicate bit-patterns in memory that are very hard, if not<br>
impossible, to share.<br>
<br>
The simplest case are two equivalent instances of DateAndTime (read<br>
from separate files). Despite being equivalent, their<br>
utcMicroseconds' will be separate objects each consuming separate<br>
memory space. There is no easy way to share the same<br>
'utcMicroseconds' instance between them.<br>
<br>
But fully-equivalent DateAndTime's is not even half of the concern --<br>
the high-order bits of every DateAndTime's 'utcMicroseconds'<br>
duplicates the same bit pattern, again and again, eating up memory.<br>
<br>
That doesn't happen when the internal representations are, or can be,<br>
canonicalized, as in the case of using SmallIntegers. Yes, Brent's<br>
original representation requires two additional slots per instance,<br>
but the _contents_ of those slots are SmallIntegers -- shared memory.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br>Well, in current 32 bit image format, SmallInteger are not exactly shared, they are immediate values.<br></div><div>Each consumes exactly 32 bits.<br><br>
</div><div>For a compact class like LargePosOrNegInteger, I don't remember what is the header size exactly, but you get 64 bits for data, I would be surprised to see a major difference wrt consumed memory.<br><br></div>
<div>Nicolas<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
<br>
On Mon, May 26, 2014 at 8:29 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> On Mon, May 26, 2014 at 01:09:06PM -0500, Chris Muller wrote:<br>
>> Hi Dave, as someone who works with large systems in Squeak, I'm always<br>
>> interested in _storage efficiency_ as much as execution efficiency.<br>
>><br>
>> DateAndTime, in particular, is a very common domain element with a<br>
>> high potential for there to be many millions of instances in a given<br>
>> domain model.<br>
>><br>
>> Apps which have millions of objects with merely a Date attribute can<br>
>> canonicalize them.<br>
>> And, apps which have millions of Time objects can canonicalize them.<br>
>><br>
>> But LargeInteger's are not easy to canonicalize (e.g.,<br>
>> utcMicroseconds). So a database system with millions of DateAndTime's<br>
>> would have to do _two_ reads for every DateAndTime instance instead of<br>
>> just one today (because SmallIntegers are immediate, while<br>
>> LargeIntegers require their own storage buffer).<br>
><br>
> Hi Chris,<br>
><br>
> I do not have a lot of experience with database systems, so I would<br>
> like to better understand the issue for storage of large numeric values.<br>
><br>
> I was under the impression that modern SQL databases provide direct<br>
> support for large integer data types (e.g. bigint for SQL server), and my<br>
> assumption was that object databases such as Magma or GemStone would<br>
> make this a non-issue. Why is it that a large (64 bit) integer should<br>
> be any more or less difficult to persist than a small integer?<br>
><br>
> This may be a dumb question but I am curious.<br>
><br>
> Thanks,<br>
> Dave<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>