Profiling Magik performance in Emacs

Magik applications often appear slow for several different reasons: an inefficient method, a collection rebuilt on every request, or delay in the editor-to-runtime connection. Emacs can expose the editor side of that delay, while Smallworld profiling can reveal where runtime work accumulates. Keeping those measurements separate prevents a slow network round trip from being mistaken for an expensive Magik routine.

For teams in Sydney, Melbourne and Perth maintaining utility and infrastructure software, this distinction is practical rather than academic. A useful performance investigation starts with a repeatable workload, measures both environments, and preserves enough context to explain why the same operation behaved differently on another Australian site.

Built-in tool	What it reveals	Best fit for Magik work	Important boundary
benchmark-run	Elapsed, user and system time plus Emacs garbage-collection statistics	Comparing editor commands and repeated submissions	Measures the Lisp path unless the request and its waiting time are included
profiler-start and profiler-report	A sampled Emacs Lisp call tree	Finding expensive completion, navigation or process-handling helpers	Does not automatically attribute time inside Magik
timeit	Elapsed time for a particular Lisp expression	Quick comparisons of small helper functions	Provides little context about the wider workload
debug-on-quit and debug	An interactive Lisp backtrace	Diagnosing stuck editor commands and callbacks	Best suited to failures rather than routine latency
trace and trace-region	An ordered trace of selected calls	Checking cache, file and process-handling behaviour	Adds overhead and can create substantial output

Establish a reproducible baseline

Begin with one operation that a user can describe in plain language, such as refreshing a network model or generating a spatial report. Freeze its inputs, Smallworld release, transaction mode, cache state and client configuration. Record the same operation on every machine; otherwise a database difference can look like a code regression.

Use benchmark-run around the actual Emacs command that submits the request, including any cache lookup and process communication. Its report separates real, user and system time and includes Emacs garbage-collection information. Run several repetitions, and keep both cold-cache and warm-cache cases because they answer different questions.

Store the machine type, operating system, Smallworld version, dataset identifier and relevant Emacs settings. For Australian support teams, log both UTC and the local AEST or AEDT label; daylight-saving changes can otherwise make incident timelines confusing. A team using Windows desktops for Smallworld alongside Unix-based build servers should record both client types, since path handling and process overhead can differ.

Separate editor overhead from runtime cost

profiler-start and profiler-report are Emacs’ native sampling tools. They build a call tree for Emacs Lisp execution, which is ideal for finding expensive completion, folding, navigation, hooks or process-handling helpers in a Magik editing session. A method dispatched to the Smallworld runtime will not appear as a native Magik hotspot merely because it was launched from Emacs.

Start the profiler before the operation and stop it afterwards with profiler-stop. The default sampling interval is 10 milliseconds with a 200-sample ceiling; adjust either only with a reason, and repeat important comparisons under identical settings. profiler-report-mode lets you expand or collapse nodes instead of rerunning the workload for every hypothesis.

Read the shape of the report before chasing a single function. Broad Lisp time may point to a hook or repeated buffer scan, while a small user time paired with long real time often suggests waiting for the inferior process, a file or a network service. Confirm such a wait with timestamps from both ends rather than labelling the Magik method slow.

Measure execution inside the Smallworld process

Smallworld releases provide their own runtime profiling facilities, and those results are necessary when the Magik method itself dominates. Use the profiler interfaces documented for the installed release to collect timing by method and, where available, distinguish inclusive time from time spent in each operation. Save the resulting report with the scenario name so it can be opened directly in Emacs or attached to a ticket.

Common targets include repeated sw:vector or sw:collection traversal, database query construction, index lookup and cache rebuilding. A method can also spend time crossing the process boundary many times for data that could have been returned in one request. The native report is better evidence for these questions than an editor-side call tree, especially when calls are distributed across helper methods.

Remote locations make wall-clock timing harder to interpret. An application hosted in Sydney may answer a Perth engineer after an extra network hop, while the Smallworld host and the desktop can each add delay. Record elapsed time at the host and at Emacs, synchronise their clocks, and compare them with the process timing. If the gap is elsewhere, optimise the application rather than rewriting a correct Magik method.

Trace calls and inspect working objects

When Emacs appears stuck, set debug-on-quit to non-nil, reproduce the problem and press C-g. Emacs enters its debugger and shows the Lisp backtrace, revealing the editor-side path that led to the failure. debug can also be invoked directly for a selected expression. These tools show Emacs Lisp frames; use the Magik debugger in the Smallworld environment when you need the native Magik stack.

For narrower checks, trace can follow selected Lisp functions, and trace-region can record calls across a chosen region. Trace a small helper or request adapter rather than a whole editing session. The output can confirm whether a cache was consulted, an unexpected file was opened or a process callback ran repeatedly. Because tracing adds work and creates output, treat it as an explanation tool, not a timing measurement.

Pair the trace with Magik object inspection in the Smallworld development environment. Check collection sizes, index use, object counts and the validity of assumptions inside a hot method. Method navigation helps compare the suspected helper with its caller. For Australian electricity or water-network datasets, use aggregated or synthetic examples in shared reports so customer information is not exposed through debugging artefacts.

Turn profiling into a repeatable check

A profiling result becomes useful when it supports a before-and-after decision. Keep the workload, data, cache preparation and machine configuration fixed, then change one implementation detail. Use benchmark-run for the Emacs path and the Smallworld profiler for the runtime path. Report the median and spread across repetitions, along with the clearest hotspot, instead of relying on a single favourable run.

Build a small Emacs Lisp harness for the scenario and print the scenario name, release, repeat count, real time, user time, system time and Emacs garbage-collection figures. Attach the corresponding native profile identifier. Keep the harness beside the test data and run it after every relevant change; this turns a one-off investigation into a regression check that developers can repeat from their own desks.

Share the call tree, timings, reproduction steps and environment notes, while removing proprietary code or sensitive records from images and logs. The available extensions and setup resources are listed under Magik Emacs downloads, and HydePark Consulting can help teams adapt the workflow to their supported Smallworld release and internal support process.

---

Choose one representative operation and collect a baseline before changing any code. Stop the profiler at the same point in that scenario, capture the Smallworld-side timing, and save the command used to reproduce it. That short trail gives the team evidence it can trust and a clear candidate for further investigation.

Install the relevant Emacs extension, run the same benchmark with the proposed change, and publish the comparison in your team’s engineering channel. Magik Emacs tutorials, news and screen-casts can support broader training, while HydePark Consulting can assist with profiling setup, consulting and release-specific troubleshooting. Start with the baseline, make the next change deliberately, and measure the result.