[Vm-dev] Could someone add a VMMaker Inbox project to source.squeak.org?

Chris Muller asqueaker at gmail.com
Tue Oct 2 20:11:03 UTC 2018

There are a number of factors that combine to lead to occasional
timeouts depending on the package.

In this case, VMMaker is a huge package, and it takes a long time for
the server to open up the .mcz and materialize its contents.  That's
why, for example, the diffing operation, which doesn't use Magma at
all, times out.

When a new version of VMMaker is saved, once again, it must be opened
up by the server and then, all of its MCDefinitions are enumerated and
indexed into huge Dictionary's stored by Magma.  This takes a long
time and even though it occurs in a background local Smalltalk
Process, it can affect local image performance.

Another cause are the many thousands of files which the server must
constantly refresh its directory cache, again and again, as it grows
ever larger.

Yet another issue is the dual persistence -- currently since we use
both File-based AND Magma, we have to save a "data.obj" file, and so
we're forced to keep the entire model into memory instead of taking
advantage of Magma's ability to work efficiently with subgraphs of
models.  But this is the only way we can have the MC history and
origin functions.

As I run the exact same code repository on my laptops to manage my own
code as runs source.squeak.org, after Squeak 5.2, I plan to refresh
and test my own codebase, bring it up to 64-bit, latest Magma, and
make some optimizations.  I'll test it by running my own development
with it for a while and then apply the same upgrades to

 - Chris
On Tue, Oct 2, 2018 at 12:08 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:
> My impression is that these slowdowns are present since the update to the
> Magma backend.
> I haven't seen the code yet, but I presume the code accessing data from
> Magma is responsible for this, and someone familiar with Magma can easily
> fix it.
> Levente

More information about the Vm-dev mailing list