String comparison still uses primitives.
When there's a collation specified, primitive 158 is used 
(Collections-ul.900). When there is no collation specified, there's an 
additional message send to the "old" code which uses the "old" primitive 
when possible.


Levente

On Wed, 24 Jun 2020, Nicolas Cellier wrote:

> A wild guess: String comparison primitive disabled due to jit problem
> 
> Le mer. 24 juin 2020 à 08:58, Jakob Reschke <forums.jakob at resfarm.de> a écrit :
>       Forgot the time frame: I am looking for something that changed between
>       2020-06-14 and 2020-06-22.
>
>       The builds run unconditionally every weekend to notice Trunk breakages
>       and were fine on 2020-06-14.
>
>       Am Mi., 24. Juni 2020 um 08:43 Uhr schrieb Jakob Reschke
>       <forums.jakob at resfarm.de>:
>       >
>       > Hi all,
>       >
>       > On Monday I noticed that some Squot tests started to fail on Travis CI
>       > due to timeouts (test cases exceeding the 5 sec default timeout). The
>       > problems are not due to changes in Squot itself because if I retrigger
>       > an older build which was already green, it also fails. So I suspect a
>       > change in Squeak Trunk, since the Squeak 5.2 builds are also not
>       > affected.
>       >
>       > I did not yet find the cause, but would like to make known what I
>       > found so far. Does anyone have an idea what could have caused this? Of
>       > course I don't expect you to debug my test cases, but maybe you have a
>       > hint for me.
>       >
>       > - The Mac builds are much more affected than the Linux builds. This
>       > could be due to differences in Travis CI's setup for the operating
>       > systems. The Linux test runs also got slower, but not by so much.
>       > - Both the 64 bit and 32 bit Mac builds got slower. The 64 bit ones
>       > scratch at the 5 sec mark, but did not exceed it yet.
>       > - If I repeat older Mac builds, they experience the same slowdown.
>       > - The tests on Squeak 5.2 are unaffected on either platform.
>       > - Some tests take about 6x up to 20x more time than before. On Linux
>       > it is only up to x3 times slower and in sum hardly noticeable. For the
>       > rest of this, I will only talk about the Mac Trunk builds.
>       > - testTrackingAPackage has the worst ratio, whereas testTrackingAClass
>       > is virtually unaffected.
>       > - Only tests that involve whole packages, not individual objects or
>       > single classes, seem to be affected. Is the regression in something
>       > that PackageInfo does (enumerating classes, methods, accessing
>       > categories)?
>       > - Surprisingly, the tests with Git are less worse than the tests with
>       > a stub in-memory repository (these are the same test cases, but with a
>       > different backend object). I think the Git tests by chance ran after
>       > the in-memory tests, maybe that affects things, I don't know yet. The
>       > Git tests did not reach the 5 sec mark.
>       > - Tests that involve Monticello (such as the Monticello->Git
>       > conversion) and do not only create MCDefinitions and pass them around,
>       > take about 2x as long now.
>       >
>       > For reference:
>       > Good build: https://travis-ci.org/github/hpi-swa/Squot/jobs/698280144
>       > Bad build: https://travis-ci.org/github/hpi-swa/Squot/jobs/700640404
>       > The runtimes are annotated to the test cases when you expand them.
>       > If you do want to look at the code, just load the Git Browser, then
>       > you will also have the test cases.
>       >
>       > If I find out more on the weekend, I will post again.
>       >
>       > Kind regards,
>       > Jakob
> 
> 
> 
>