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