Raw pane on byteStrings

Hi Andrei,

Le 26/02/2017 à 23:48, Andrei Chis a écrit :

Hi Thierry,

Thanks for the measurements. Things are more clear now :)

On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier
<[hidden email] <mailto:[hidden email]>> wrote:

    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"


Indeed this is what I expected.




        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".


Can you just also try to remove the Items view and set
indexableDisplayLimit to 50.

In the previous times, the Item view was removed. If indexableDisplayLimit is set at 50, then the time become:

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

Which is interesting in itself: multiplying the limit by 1000 (from 50 to 50k) increase the time by a factor of ~1.6.

I think there is some small performance degradation in the current tree
data source used by Glamour but I'm not 100% sure.

It looks pretty efficient to me. There isn't much increase in times.

I looked at the scaling in my experiment: the lower bound in opening the inspector is reached for a 100k elements array. Anything smaller
has the same time (~80ms). The 1000k array increase that by ~15/20ms.

        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.


Nice. Would be also interesting to see if in the future we can merge
more the models used by GTInspector and EyeInspector.

Could be. I just used them out of convenience, and I needed an inspector with the ability to view large trees.

For now, for the Raw view I set the limit to 5000 elements. This seems
fast/large enough and it allows to add the automatic refresh back to the
Raw view.

I wonder if it wouldn't be possible to tune the automatic refresh. Increase the time interval if it takes to long (for example when refreshing a set with 1M elements). But 5000 elements is already a good limit.

Regards,

Thierry

Cheers,
Andrei




        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
    <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
    <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
        [hidden email]:pharo-project/pharo-vm.git Commit:
        06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30
        08:40:43 +0200
        By: GitHub <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email] <mailto:[hidden email]>>>

        Cheers,
        Andrei


        On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier
        <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email]
        <mailto:[hidden email]>>> wrote:



            2017-02-24 14:29 GMT+01:00 Andrei Chis
        <[hidden email] <mailto:[hidden email]>
            <mailto:[hidden email]
        <mailto:[hidden email]>>>:



                On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier
                <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]
        <mailto:[hidden email]>>>
                wrote:

                    Hi Andrei,

                    2017-02-24 11:31 GMT+01:00 Andrei Chis
                    <[hidden email]
        <mailto:[hidden email]>
                    <mailto:[hidden email]

        <mailto:[hidden email]>>>:


                        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
                        <[hidden email]
        <mailto:[hidden email]>

                        <mailto:[hidden email]
        <mailto:[hidden email]>>> 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
                            <[hidden email]
        <mailto:[hidden email]>
                            <mailto:[hidden email]

        <mailto:[hidden email]>>>:

                                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"
                                <[hidden email]

        <mailto:[hidden email]> <mailto:[hidden email]
        <mailto:[hidden email]>>>
                                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