[Pharo-dev] Raw pane on byteStrings

Thierry Goubier thierry.goubier at gmail.com
Fri Feb 24 17:52:53 EST 2017


Hi Andrei,

Le 24/02/2017 à 17:02, Andrei Chis a écrit :
> 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"

Yes, this is expected. I'm not comparing to the standard EyeInspector, 
but with my experiments with a FastTable-derived widget and the 
EyeInspector model. GTInspector is a lot faster than the normal 
EyeInspector.

As default (the only one displaying 100k elements is the AltInspector)

| array |
array := (1 to: 1000000) asArray.
[AltInspector inspect: array ] timeToRun. "0:00:00:00.096"
[EyeInspector inspect: array] timeToRun.  "0:00:00:00.364"
[GTInspector inspect: array] timeToRun. "0:00:00:00.065"

> If I change indexableDisplayLimit to 50000 and remove the Items view
> then I get:
>
> [GTInspector inspect: array] timeToRun.  "0:00:00:00.124"

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

So this time is to be compared to the "0:00:00:00.096".

> I'm really interested in seeing what makes GTInspector slower on your
> machine. Did you do other optimizations to SpecInspector?

The optimisations are:
- remove Spec (revert to a pure morphic application),
- use a FastTable-derived widget for a tree view (with a 100k element 
limit),
- have the GT views as subitems in the widget.

> I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7

Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest.

5.0-201702231204  Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production 
Spur ITHB VM]
CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 
40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 
40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
VM: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Date: 
Thu Feb 23 13:04:59 2017 +0100 $
Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git $
Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 
4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 
i686 i386 GNU/Linux


> 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 <mailto:noreply at github.com>>
>
> Cheers,
> Andrei
>
>
> On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier
> <thierry.goubier at gmail.com <mailto:thierry.goubier at gmail.com>> wrote:
>
>
>
>     2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei at gmail.com
>     <mailto:chisvasileandrei at gmail.com>>:
>
>
>
>         On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier
>         <thierry.goubier at gmail.com <mailto:thierry.goubier at gmail.com>>
>         wrote:
>
>             Hi Andrei,
>
>             2017-02-24 11:31 GMT+01:00 Andrei Chis
>             <chisvasileandrei at gmail.com
>             <mailto: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
>                 <mailto: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
>                     <mailto: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 <mailto: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
>
>
>
>
>
>
>




More information about the Pharo-dev mailing list