On Jan 16, 2015, at 7:55 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi All,
> 
> On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
>> Hi Marcel,
>> 
>> On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <marcel.taeumel at student.hpi.uni-potsdam.de> wrote:
>> 
>>> Ah, okay. I was curious about the performance of iterating over an array vs.
>>> the linked list:
>>> 
>>> a := Array new: 1000.
>>> l := LinkedList new.
>>> 
>>> 1000 timesRepeat: [l add: (StackLink with: nil)].
>>> 
>>> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
>>> 
>>> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
>>> 
>>> I expected the opposite! :-O Why is that so?
>> 
>> Look at the implementations of do:.
>> 
>> In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element.
>> 
>> In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element.
> 
> This is interesting.  (Marcel, Chris, forgive me; I'm presuming; please don't take this personally).  Marcel above appears to lack an intuition about the structure of Array vs LinkedList.  And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers.
> 
> As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head.  Those pictures are key to my approach to design and optimization.
> 

and lest anyone think I have no problem developing these pictures, elsewhere in the thread Levente discussed the linked hash map organization of OrderedDictionary.  It took me the few minutes in which I drafted an erroneous and unsent email to develop the picture that made me realize Levente was right about lookup being O(1) because I didn't have the picture of a link in my head when I started writing the email.

> I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model.  For me, I read the blue book first, which is replete with pictures.
> 
> I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs.  I wonder how useful it would be to provide support for designers to include pictorial representations in class comments.
> 
> Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment.
> 
> A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration.
> 
> Either approach would make an interesting project, yes?
> 
>>> Best,
>>> Marcel
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: http://forum.world.st/The-Trunk-Collections-mt-593-mcz-tp4799750p4799893.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>