Collections issue

Brent Pinkney brent at zamail.co.za
Mon May 17 05:36:13 UTC 2010


Hi,

> Hi,
> I'm using Magma r42 on Pharo 1.0 and I have this situation:
>
> "2356 Cities"
> Time millisecondsToRun: 
> [mySession root states first cities do: [:each 
>
> |  Transcript show: each]]  "16178 milliseconds"
>
> mySession root answer a singleton that have 23 states and the first state
> has 2356 cities. Is 16178 milliseconds the expected time for accessing to
> it?
> states and cities are OrderedCollection instances. Must I change it to
> MagmaCollection for better performance?

Hi Facundo,

I recommend you think in terms of "poxy agitation" and "materialisation" to 
understand how a _transparent_ database works.

01. When you evaluate "mySession root" there is a rount-trip to the Magma server get the root object.
02. This then gets materialised if it it not already in the image.
03. All the root object's instance variables are proxies.
04. When you send #states, you agitate the proxy in the 'state' instance variable.
05. The proxy fetches the OrderedCollection and all 50 states (but not their instance variables). 
06. These are materialised and the proxy replaced.
07. When you send first, the newly materialised OrderedCollection responds immediately.
08. When you send #cities, you agistate the proxy in the 'cities' instance variable.
09. The proxy fetches the OrderedCollection and all 2356 cities (but not their instance variables). 
10. These are materialised and the proxy replaced.
11. When you send #do: it is executed by the OrderedCollection immediately.
12. The #do: sends #value: to the block passing the first City instance.
13. The blocks sends #printString, via #show: to the City.
14. Assuming the #printString prints the city's name, the name instance variable is agitated.
15. The proxy fetches the name String and materialised it.
16. The city is shown on the Transcript.
17. Repeat 13-17 another 2355 times.

So,
a) Large OrderedCollections are slow becuase the entire OrderedCollection is materialised, 
    even if you only want the first State.

b) Consider MagmaCollections to fetch a State by name:
    ca = session root state where: [ :s | s name = 'California' ].

b) Materialisation of complex graphs of real Smalltalk objects is much slower than reading a
    row of primitive types from an SQL table. Alas.

c) You can minimise materialisation round-trips by using a ReadStrategy. For example, a City
   should _always_ materialise its 'name' instance variable whenever a City is materialised.

Respond to the list if you need more help.

Brent


More information about the Magma mailing list