[Pharo-dev] Raw pane on byteStrings

Thierry Goubier thierry.goubier at gmail.com
Fri Feb 24 09:45:34 EST 2017

2017-02-24 15:28 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:

> 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170224/52490edf/attachment.html>

More information about the Pharo-dev mailing list