Hi Thierry, On Fri, Feb 24, 2017 at 3:49 PM, Thierry Goubier <[email protected]> wrote:
> > > 2017-02-24 15:43 GMT+01:00 Andrei Chis <[email protected]>: > >> >> >> On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov <[email protected]> >> wrote: >> >>> >>> 2017-02-24 14:29 GMT+01:00 Andrei Chis <[email protected]>: >>> >>>> 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 > > > > >
