Hi Thierry, On Fri, Feb 24, 2017 at 3:49 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2017-02-24 15:43 GMT+01:00 Andrei Chis <chisvasileandrei@gmail.com>:
On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei@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
This is how the inspector works for the Items view for Array objects. It also does not use any wrappers and only computes visible part.
As I said, it brings in a lazy data source adapted to arrays in a case where it may well be not needed. My experiments show that there is no need for this optimisation, at least for arrays ~ 100k.
For this particular case there is no special lazy data source. It's just the default table data source from Glamour. In works in this particular case because for a SequenceableCollection we currently have no wrapping of elements, so we can just extract them directly. Will be worth looking for a lazy data source for a remote inspector but not for Pharo 6. Cheers, Andrei
Thierry