Skip to content
Get a Demo
All Field Notes

Smallworld 5: initial observations

The 25-year-old Magik VM replaced by the JVM: first observations from an early Smallworld 5 upgrade.

From the archive: republished from the original Cliffhanger blog, June 2016. Lightly reformatted; the words are as they were.

With the introduction of Smallworld 5.0, the 25-year-old Magik VM has been replaced with the Java VM. Smallworld developers can still develop in the Magik language, but the code compiles into Java byte-code and no longer into Magik byte code. This will open up the proprietary Magik environment to the world of Java, at least that’s the idea.

For one of our clients, we maintain their GIS, which is (obviously) Smallworld from GE. This application has a good number of [layered] products, including Design Manager and SOMS and a fair amount of customizations. To give the hardcore Smallworld techies an idea, a version 4 closed image would run about 50MB.

So we started upgrading this app to version 5.0 and here are some of the initial findings:

In Smallworld 4 and before, you compile all Magik code and then save that as an image. This is comparable to a Jar file, but it contains Magik bytecode. You can then connect a database and save the result as an open image, which will speed up startup time because the DB connections are already cached.

In version 5.0 the are no images. Instead, Smallworld modules can be compiled into Jar files.

Startup performance

This has many implications, including start-up time. See table. In Smallworld 4 when you start an open image, you almost immediately get the familiar “open database” dialog.

Smallworld startup was never fast but this is a significant increase. Total start-up time is 2.4 times slower in 5.0 (we will post our findings as soon as we have a chance to test this in 5.1. as we’ve been informed that start-up time in 5.1 has been significantly improved). Although we didn’t run a full benchmark, there also appear to be some advantages. Running pure Magik seems quite a bit faster. However, opening UI widgets is a bit slower. Database interactions is a toss-up.

Note that we ran both SW4 and SW5.0 on the same hardware. Also, note that our case might not be representative of other Smallworld installations. That being said, after doing Smallworld for 25 years, we’ve seen many installations, and we think this one is fairly average in size and number of connected data sets.

Memory Use

Without tweaking, Memory use appears to have increased, jumping from just under 200MB (for sw_magik_win32.exe) to almost 1GB (for java.exe). This comparison was without further tweaking (memory usage depends on a large number of variables).

If there are others out there that have been able to get a good startup performance, we’d be very interested. Shoot us a note or leave a comment down below.

IDE

Also, with Smallworld version 5.0, GE has dropped official support for Emacs in favor of MDT, which is Eclipse based. Hardcore developers might not want to use Eclipse (I doubt the folks in Cambridge use it), but fortunately using Emacs is still possible with a few tricks. More about that [here]

 

 

 

Pilot to Production

See it on your network.

If this note sounds like your shop, that's a good place to start: one workflow, your systems, and a baseline captured on day one.