<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">[Let's move that part of the discussion here]</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"></div></div></div></div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Our virtual server might be significantly slower than your machine. But it still seems suspiciously slow, agreed.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -</div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 3:54 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
On Tue, 2 Oct 2018, Chris Muller wrote:<br>
<br>
> <br>
> There are a number of factors that combine to lead to occasional<br>
> timeouts depending on the package.<br>
><br>
> In this case, VMMaker is a huge package, and it takes a long time for<br>
> the server to open up the .mcz and materialize its contents.  That's<br>
> why, for example, the diffing operation, which doesn't use Magma at<br>
> all, times out.<br>
<br>
I measured diff creation on my machine using various VMMaker versions:<br>
- creating a diff of 2 versions takes less than 2 seconds<br>
- from this 2 seconds the actuall diff creation takes about 150ms, which <br>
can easily be halved with some basic optimizations<br>
- more than a second is spent by DataStream reading and mangling strings <br>
for no real reason. We should be able to significantly reduce that as <br>
well.<br>
- the remaining few hundred milliseconds is spent on parsing the ancestry,<br>
which can only be solved by using a new non-recursive ancestry format <br>
which doesn't require you to parse everything to read a single entry.<br>
<br>
But 2 seconds is not enough to get a 504 response, so there must be some <br>
other reason for those timeouts.<br>
<br>
Levente<br>
<br>
><br>
> When a new version of VMMaker is saved, once again, it must be opened<br>
> up by the server and then, all of its MCDefinitions are enumerated and<br>
> indexed into huge Dictionary's stored by Magma.  This takes a long<br>
> time and even though it occurs in a background local Smalltalk<br>
> Process, it can affect local image performance.<br>
><br>
> Another cause are the many thousands of files which the server must<br>
> constantly refresh its directory cache, again and again, as it grows<br>
> ever larger.<br>
><br>
> Yet another issue is the dual persistence -- currently since we use<br>
> both File-based AND Magma, we have to save a "data.obj" file, and so<br>
> we're forced to keep the entire model into memory instead of taking<br>
> advantage of Magma's ability to work efficiently with subgraphs of<br>
> models.  But this is the only way we can have the MC history and<br>
> origin functions.<br>
><br>
> As I run the exact same code repository on my laptops to manage my own<br>
> code as runs <a href="http://source.squeak.org" rel="noreferrer" target="_blank">source.squeak.org</a>, after Squeak 5.2, I plan to refresh<br>
> and test my own codebase, bring it up to 64-bit, latest Magma, and<br>
> make some optimizations.  I'll test it by running my own development<br>
> with it for a while and then apply the same upgrades to<br>
> <a href="http://source.squeak.org" rel="noreferrer" target="_blank">source.squeak.org</a>.<br>
><br>
> - Chris<br>
> On Tue, Oct 2, 2018 at 12:08 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
>><br>
>><br>
>> My impression is that these slowdowns are present since the update to the<br>
>> Magma backend.<br>
>> I haven't seen the code yet, but I presume the code accessing data from<br>
>> Magma is responsible for this, and someone familiar with Magma can easily<br>
>> fix it.<br>
>><br>
>> Levente<br>
</blockquote></div></div>