2017-02-24 15:28 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > > 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileand...@gmail.com>: > >> There should be no hidden costs in GTInspectorIndexedNodes. >> I made some experiments in the latest Pharo version and opening the Raw >> view on an array with one million numbers takes around 120ms when 100k >> elements are computed. >> I'll be curious how much it takes on your machine. To test update >> indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: >> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that >> the Items presentation is not loaded) >> >> arrayLarge := (1 to: 1000000) asArray. >> > > I really wondering why anybody want instantiate wrapper objects for all > array items? Fast table approach is to not do that. Only visible part of > items should be recreated >
If you want. The fasttable code does the first thing of not creating a wrapper interactive representation for all elements (i.e. a Morph). Then the datasources may also be lazy: only wrap the objects for which a representation is asked. The thing is that to be able to plan that in totally generic UIs like an inspector, is that you need to create placeholders (one way or another) to let the UI knows what kind and how many elements the datasource holds... if the cost is low enough, just creating a placeholder for each element may turn out to be just fine. And the truth is, in local memory, creating a placeholder for every element in a 100k collection costs about 0. Remote can be handled either by a lazy source, or just by blindly creating placeholders and caching the accesses to the real remote objects (with the fact that you can expect that remote requests are only done when displaying the element, not when building the widget). Simple, easy, fast enough, and maybe better than considering than a lazy source on a remote source is a ad-hoc implementation of a cache. Regards, Thierry
