2017-02-24 14:29 GMT+01:00 Andrei Chis <[email protected]>: > > > On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier < > [email protected]> wrote: > >> Hi Andrei, >> >> 2017-02-24 11:31 GMT+01:00 Andrei Chis <[email protected]>: >> >>> Hi Thierry, >>> >>> Indeed that's the simplest option now that we are using fast table. >>> >>> Just now in the case of the Raw view an OrderedCollection is used to >>> store all displayed elements. >>> If you display large collections every time you open the Raw view it >>> will instantiate a collection of size 100k and instantiate 100k objects >>> of type GTInspectorIndexedNode. With FastTable we can lazily load elements >>> so we should be able to remove this behaviour and the limit. Just we need >>> to make sure it will play nicely with automatic refresh. There is also the >>> issue that when expanding an element in the tree if it's a collection you >>> don't want to expand all elements. >>> >> >> I'm not sure you need to worry too much about that one; in practical >> experiments, creating that 100k collection for viewing (and the associated >> nodes instances) isn't too costly (unless creating the >> GTInspectorIndexedNodes has hidden costs: I've only experimented with the >> EyeInspector framework). >> > > 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. > arrayLarge inspect. >
This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); both inspectors displays 100k elements. (1 to: 1000000) asArray in: [ :s | [s inspect] timeToRun] 0:00:00:00.064 (1 to: 1000000) asArray in: [:s | [GTInspector inspect: s] timeToRun] 0:00:00:00.381 Pharo 6 60411 > > >> >> Opening the tree with all elements works fine in my experiments. Tuning >> scrolling as done in Bloc is necessary, however. >> >> >>> >>> I'm looking now on a lazy data source for FastTable that plays nicely >>> with GTInspector. Let's see how it will go. Help is always welcomed :) >>> >> >> As I said: do not overoptimize that part... just remove that limitation >> on the raw view and measure. >> > > If I measure the Items view on the previous array it takes around 35ms. > What I'd like to have is the same opening time for the Items view on large > Sets and Dictionaries. > On my machine, the experiment is that displaying the set is fast, but the system becomes totally unresponsive... which may be an issue with the self refresh of the inspector. Yes, it was the culprit. (1 to: 1000000) asSet in: [ :s | [s inspect] timeToRun] 0:00:00:00.034 (1 to: 1000000) asSet in: [:s | [GTInspector inspect: s] timeToRun] 0:00:00:00.199 Regards, Thierry > > >> >> >>> >>> I think I used the word paginator in the wrong way. If you have a very >>> large collection (millions of elements) I do not want to scroll through >>> elements but most likely jump to a certain element or view just a subset of >>> all elements. Not really add a paginator like in web pages. >>> >> >> Ok, millions of elements is a bit out of my scope... I'll look for >> filtering then. >> > > Yes, definitely filtering is the way to go there :) > > Cheers, > Andrei > > >> >> Regards, >> >> Thierry >> >> >>> >>> Cheers, >>> Andrei >>> >>> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier < >>> [email protected]> wrote: >>> >>>> Hi Andrei, >>>> >>>> if you're using fasttable for the Raw view, you should be able to reach >>>> one 100k elements without issues. I did some experiments and it handles the >>>> load very well. >>>> >>>> Avoid the paginator at any cost. This thing is really user-unfriendly. >>>> >>>> Regards, >>>> >>>> Thierry >>>> >>>> 2017-02-23 20:19 GMT+01:00 Andrei Chis <[email protected]>: >>>> >>>>> Hi Stef, >>>>> >>>>> Currently that's the default behaviour of the Raw view: it displays >>>>> for collections only the first and the last 21 elements. The Items view >>>>> however always should display all the elements of a collection. >>>>> >>>>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6 >>>>> now the speed of the Raw view is greately improved so we could increase >>>>> those limits. Still for now there should still be some limit for the Raw >>>>> view. Ideally we should add a small widget, something like a paginator, >>>>> for >>>>> navigating through large and very large collections. >>>>> >>>>> Cheers, >>>>> Andrei >>>>> >>>>> On Feb 23, 2017 19:35, "stepharong" <[email protected]> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I'm trying to debug citezen generation and I have to compare strings. >>>>>> Now I think that the raw views (in Pharo 50) is not good because we >>>>>> cannot see all the items in raw format. >>>>>> See the attachements. It jumps from 21 to 174 ... >>>>>> and what I want to see is of course in the middle. >>>>>> >>>>>> Is it me or there is something wrong there. >>>>>> Stef >>>>> >>>>> >>>> >>> >> >
