[Pharo-dev] Raw pane on byteStrings

Andrei Chis chisvasileandrei at gmail.com
Fri Feb 24 11:02:58 EST 2017


Hi Thierry,

Strangely enough I'm getting different times on my machine
Just to start from the same baseline in a fresh Pharo 60411 image with no
changes to any of the inspectors over a series of runs I get:

array := (1 to: 1000000) asArray.
[array inspect] timeToRun.                       "0:00:00:00.145"
[GTInspector inspect: array] timeToRun. "0:00:00:00.031"

If I change indexableDisplayLimit to 50000 and remove the Items view then I
get:

[GTInspector inspect: array] timeToRun.  "0:00:00:00.124"

I'm really interested in seeing what makes GTInspector slower on your
machine. Did you do other optimizations to SpecInspector?
I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7

Pharo VM version:
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
git at github.com:pharo-project/pharo-vm.git Commit:
06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
By: GitHub <noreply at github.com>

Cheers,
Andrei


On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier <thierry.goubier at gmail.com>
wrote:

>
>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei at gmail.com>:
>
>>
>>
>> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier <
>> thierry.goubier at gmail.com> wrote:
>>
>>> Hi Andrei,
>>>
>>> 2017-02-24 11:31 GMT+01:00 Andrei Chis <chisvasileandrei at gmail.com>:
>>>
>>>> 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 <
>>>> thierry.goubier at gmail.com> 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 <chisvasileandrei at gmail.com>:
>>>>>
>>>>>> 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" <stepharong at free.fr> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170224/8ba117b2/attachment.html>


More information about the Pharo-dev mailing list