Hi Christoph,

   apologies for the late reply.  Busy weekend trying to get the Vm to run
if compiled with MSVC.  Still not out of the woods...

On Fri, Mar 27, 2020 at 9:10 AM Christoph Thiede <
christoph.thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Eliot,
>
> > Quite right.  Can you find out how common cases like these are?  I bet
> you
> > there will be five methods or less in trunk that are affected.
>
> I did a full search in my image:
>
> pattern := '.*to\:[\s\r\n]*\w+[\s\r\n]*do\:[\s\r\n]*\[[^\]]*\[.*' asRegex.
> self systemNavigation allMethods select: [:m |
>         pattern matches: m getSource].
>

Well, that's not what I meant by a search.  However, as Levente pointed
out, textual searches should be surrounded with CurrentReadOlySouceFiles
cacheDuring:.  I think this is an awful implementation and would implement
it very differently but that's the work-around we have in place now,

What I meant my a search was to look at MesasageNode>>transform: which is
sent in MessageNode>>receiver:selector:arguments:precedence:from:.  This
means it is ideal.  First of all it is bottom up; the to:[by:]do: message
node is only created and transformed once all its sub components have been
parsed.  So one is in a position in MessageNode>>transformToDo: to search
the parse tree of the last block argument looking for accesses in
non-optimized blocks (*) to its argument.  (*) remember its *any* reference
in an unoptimized block, no mater how deeply nested.  So a reference to the
block argument within an optimized block that is within an unoptimized
block is till a reference.  e.g.

    1 to: 5 do:
        [:arg|
         arg even
            ifTrue: [evens add: [arg]]
            ifFalse: [odds add: [arg]]

are still references even though they're both in optimized blocks.  That's
not a good example.  I should say something like

    1 to: 5 do:
        [:arg|
         them add: [arg even
                                ifTrue: [arg]
                                ifFalse: [arg+arg]]]

whereas here it doesn't matter:

    1 to: 5 do:
        [:arg|
         them add: (arg even
                                ifTrue: [arg]
                                ifFalse: [arg+arg])]

you get the idea.  So the search is tricky.  Basically as the tree is
descended we need to either set a flag that says the search is now in an
unoptimized block, or the search needs to look up towards the root block
arg to to:[by:]do: to find an intervening unoptimized block.


> My Source Files are very slow,
> <
> http://forum.world.st/The-Inbox-ShoutCore-ct-78-mcz-tp5109909p5110050.html>
>
> so I interrupted the script after one hour, but I still found more than 250
> matches. I took some samples and they looked indeed relevant. Nested
> #to:do:
> loops, for example ...
> Or do I misunderstand your idea of a rule?
>

Yes.  It has to be something in the parse tree hiersecy, actually in
transformToDo:.  And its th cost of applying this rule during compilation
that is one3 thing to be concerned about.

Now, in orde4r to accelerate a search for candidates remember that Nicolas
wonderfully changed the compiler to add as literals the selectors of even
optimized message sends.  So for example all uses of #to:[by:]do: have the
selectors in their literal frame.  So to find out all the methods that you
want to analyze further simply start from

((self systemNavigation allCallsOn: #to:do:),
(self systemNavigation allCallsOn: #to:by:do:)) asSet asArray sorted

BTW in my VMMaker image
    ((self systemNavigation allCallsOn: #to:do:),
    (self systemNavigation allCallsOn: #to:by:do:)) asSet asArray sorted
size 2628

So you could enumerate over these, grab the parse trees, and then search
the parse trees to try and find how many methods are affected and to get a
rush idea of how expensive the search is.

However, if we can agree on leaving it as it is, it's irrelevant ;-)
>
> Best,
> Christoph
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200330/4c8c1964/attachment.html>