CelinQ Insights · No. 31

Sparx Enterprise Architect Performance: Why Local-First Can Reduce Remote Repository Latency

Interactive modelling is a conversation made of thousands of small round trips, and moving that conversation onto the local machine is what actually removes the wait.

Ask an architect who has modelled against a remote Enterprise Architect repository to describe the feeling, and they rarely reach for the word "slow" first. They reach for something more specific: a hesitation. You click an element in the Project Browser and there is a beat before its properties populate. You open a diagram and the shapes draw in, one after another, instead of appearing at once. You type a name into a field, press tab, and the cursor sits in the next field for a fraction of a second longer than it should before you can type again. None of these delays is dramatic on its own. Individually they are barely worth mentioning. But a working session in a real model is not one operation, it is thousands of them, and a hesitation repeated thousands of times a day stops being a curiosity and starts being the actual texture of the job.

This article is about where that hesitation comes from, why adding bandwidth rarely fixes it, and what changes when the architecture stops asking a remote database to be present for every click. It is also, deliberately, about how to find out whether any of this is true for your own environment rather than taking a vendor's word for it — CelinQ's included.

What an interactive modelling operation actually is

It helps to be unromantic about what happens when you click an element in Enterprise Architect. The GUI is a presentation layer over a repository, and almost everything you do generates a request against that repository: read the element's properties, read its tagged values, read the diagram objects that reference it, read the connectors attached to it, and — the moment you change anything — write the update back. When the repository is a local .eap/.eapx file or a local SQL Server or SQLite instance sitting on the same machine, each of those requests is satisfied by a call into a library that reads bytes off a local disk, typically an SSD, in well under a millisecond. The GUI feels instantaneous because the underlying data access essentially is instantaneous relative to human perception.

Point the same repository connection at a database sitting behind a WAN link, and the mechanics do not change — EA still issues the same sequence of reads and writes — but the cost of each one changes completely. Instead of a local disk read, every one of those operations becomes a network round trip: a query packet leaves your machine, crosses however many hops separate you from the database server, and a response packet has to make the same journey back before EA can render anything or accept your next keystroke. Interactive modelling, it turns out, is unusually sensitive to this because so much of what an architect does is small, granular, and constant — select an element, glance at its properties, open a related diagram, adjust a tagged value, save — rather than one big query followed by a long period of local thinking. A tool built around large, infrequent transfers would barely notice a slow link. A tool built around a continuous stream of small conversational exchanges notices immediately, because every exchange now pays the full cost of the network before it can complete.

Latency and bandwidth are not the same problem

This is the point where the instinctive fix — "get a faster connection" — usually fails to help, and it is worth being precise about why. Bandwidth is how much data a link can move per second once the conversation is underway; latency is how long it takes a single packet to make the round trip regardless of size. The queries EA issues to read a handful of properties or write a single field are tiny, often just a few kilobytes. A connection with abundant bandwidth but a long round-trip time will move that tiny query exactly as slowly as a connection with the same latency and a fraction of the bandwidth, because the bottleneck was never the size of the payload. It was the time light and electrons need to travel the physical distance between the client and the server and back again, plus whatever the network equipment along the way adds in queuing and processing.

Organisations sometimes upgrade a branch office's internet connection from a modest line to a much larger one and find that Enterprise Architect feels exactly as sluggish as before. The upgrade fixed a problem the users did not have. Their problem was round-trip time, and round-trip time is largely a function of physical distance and the number of intermediate hops, not of how many megabits the pipe can carry. A satellite link can offer generous bandwidth and still feel unusable for interactive work because the round trip to a satellite and back adds a fixed, unavoidable delay to every single exchange. Conversely, a fairly modest connection with a short, direct path to the database can feel snappier than a much larger pipe routed through several intermediate networks, because what matters for a chatty protocol is the number of round trips and the cost of each one, not the theoretical ceiling on throughput.

What a typical remote connection actually looks like

Round-trip times vary enormously depending on topology, and it is worth having a rough mental map rather than a single number, because the honest answer is "it depends, and you should measure yours." Two offices on the same metropolitan network, connected by a well-provisioned direct link, might see round trips in the range of a few milliseconds to perhaps twenty. A connection routed across a country, through a corporate VPN concentrator, and out to a data centre commonly lands somewhere in the tens of milliseconds. A connection that crosses a continent, or that adds a VPN client doing its own encryption and encapsulation on top of an already long path, regularly pushes past fifty or a hundred milliseconds. Congested links, satellite backhaul, or a VPN gateway under load can push higher still. None of these figures are CelinQ's numbers or anyone's benchmark result; they are simply the physics and topology that any network engineer will recognise, and the point of citing them is to establish why the problem is structural rather than anecdotal.

What matters for Enterprise Architect specifically is that a single visible action in the GUI is rarely one round trip. Opening a diagram might trigger reads for the diagram itself, every object on it, every connector, and the underlying elements those objects represent. If each of those reads is a separate round trip and the round-trip time is fifty milliseconds, a diagram with several dozen objects can accumulate a genuinely noticeable delay before it finishes drawing, even though no single query is slow in isolation. This is the multiplicative nature of the problem: it is not one slow operation, it is many fast operations each paying the same latency tax, and the tax adds up in direct proportion to how granular and chatty the interaction is. Working over a VPN specifically compounds this further, because the VPN tunnel typically adds its own processing and routing overhead on top of the underlying network path.

A worked example: what one diagram actually costs

It is worth walking through the arithmetic rather than gesturing at it, because the multiplicative effect is easy to state and easy to underestimate. Suppose opening a moderately complex diagram requires forty individual round trips to the repository: one to fetch the diagram record itself, roughly one per object to resolve the element it represents, a handful more to resolve the connectors between them, and a few extra for style and layout metadata that EA keeps separately. Against a local repository, each of those forty reads costs a fraction of a millisecond, so the whole diagram appears to snap into existence — the forty round trips are real, but they are so cheap that no human perceives them as separate events at all.

Now place the same repository behind a network path with a round-trip time of fifty milliseconds, which is an unremarkable figure for a corporate VPN connecting a branch office to a data centre in another city. Forty round trips at fifty milliseconds each is two full seconds, assuming EA does not parallelise the reads — and a great deal of legacy client-server data access of this kind is sequential by construction, issuing the next query only once the previous one has returned, because the logic was written assuming reads are cheap. Two seconds to open one diagram does not sound catastrophic in isolation. But an architect working through a review might open twenty or thirty diagrams in a session, edit properties on dozens of elements, and generate several reports, each of which repeats a version of the same arithmetic. The two-second delays do not stay isolated; they accumulate into minutes, then tens of minutes, spread across a working day in a way that never shows up as one dramatic outage but instead shows up as a day that took noticeably longer than it should have and a level of concentration that kept fraying at exactly the moments it needed to hold.

Push the round-trip time higher — to the hundred-to-two-hundred-millisecond range typical of a longer-haul connection, an oversubscribed VPN concentrator, or a satellite backhaul link — and the same forty-round-trip diagram moves from a two-second pause to somewhere between four and eight seconds, still for a single diagram, still before any editing has actually begun. This is the shape of the problem a benchmark needs to capture: not a single slow query, but a fixed number of small operations multiplied by a round-trip cost that the architecture either pays in full, every time, or removes from the interactive path altogether.

What stays local in CelinQ, and why that is the actual fix

CelinQ's response to this problem is architectural rather than incremental. Instead of trying to make each round trip faster — caching more aggressively, compressing payloads, tuning the protocol — it removes the round trip from the interactive path altogether. Every architect works against a genuinely local EA repository: a real .eap-based file on their own machine, read and written through EA's own engine exactly as it always has been. When you click an element, EA is not asking a distant server for its properties. It is reading a local file on local storage, the same as it would in a single-user desktop installation with no network involved at all. There is no query to send, no response to wait for, and therefore no latency to pay, because the operation never left the machine.

This is the structural difference worth dwelling on: CelinQ is not a faster way to talk to a remote database. It is a way of arranging the system so that the interactive path — the part where a human is sitting there waiting for a response — never talks to a remote database at all. The remote conversation still happens, but it happens on a different path, asynchronously, off to the side of the moment where a person is clicking and typing.

What CelinQ synchronises, and when

Nothing about local-first modelling implies that the model stays private to one machine forever. A background agent — CelinQ Connect — watches your local repository and carries your changes to a shared CelinQ Server over an encrypted gRPC connection built on Protocol Buffers, and it brings your colleagues' changes back down to you. This happens on a rhythm tuned to how the team is actually working rather than to a fixed clock: an event-driven fast path debounces a burst of edits into one coherent change a few seconds after you stop typing, a safety synchronisation runs roughly every minute to catch anything the event path missed, and a deeper reconciliation runs every five minutes to compare the whole repository against its last known state and recover from any drift. When the server's presence registry notices two or more people actively working on the same diagram, the workspace is treated as "hot" and this cadence tightens automatically, without you doing anything.

The important property of all of this is that none of it sits on the path between you and your keystroke. You are never waiting for a synchronisation to finish before EA lets you continue working, because the synchronisation is not a precondition for local reads and writes; it is a separate process that keeps the shared workspace current in the background. If the network disappears entirely, the local repository does not notice, because it was never depending on the network to function in the first place — the queued changes simply wait for a connection and replay automatically when one returns.

The question worth asking about any collaboration architecture is not "how fast is the network call," but "how many network calls sit between me and the thing I am trying to do." CelinQ's answer for interactive modelling is zero.

How to benchmark Enterprise Architect objectively

None of the reasoning above should be taken on faith, and a reader evaluating any tool in this space — including CelinQ — should insist on measuring rather than trusting a claim. A credible benchmark of EA's remote-repository performance has a fairly specific shape. First, define a small, realistic set of operations rather than a vague impression of "slowness": opening a package with a representative number of child elements, opening a diagram with a representative object count, editing a tagged value and saving, generating a document or a diagram image, and running a simple traceability query. Second, introduce latency in a controlled, repeatable way rather than relying on whatever a real office network happens to be doing that day — network emulation tools that let you shape a connection to an exact round-trip time are the right instrument here, applied between the EA client and the database so that every other variable stays fixed.

Third, run each operation many times rather than once, and report the median together with the ninety-fifth percentile rather than a single best-case number, because a single run is vulnerable to whatever else the machine or the network happened to be doing at that moment, and the tail of the distribution — the occasional very slow response — is often what a user actually remembers and complains about. Fourth, and this is easy to overlook, separate the cost of an initial clone or checkout of a whole repository from the cost of ongoing incremental work. Cloning a large model necessarily moves a large amount of data and will take time regardless of architecture; what matters far more for day-to-day productivity is the cost of the small, repeated operations that make up a normal working session once that initial clone is done. Conflating the two produces a benchmark that measures the wrong thing.

A methodology built this way — controlled latency injection, a fixed and representative operation set, repeated runs, median and P95 reporting, and a clear separation between initial synchronisation and incremental work — is what you should ask any vendor for, and it is the standard CelinQ tries to hold itself to in its own engineering. Simulating round-trip times in the range of roughly twenty, fifty, one hundred, and two hundred milliseconds against a shared-repository connection, and then repeating the same operation set against a fully local repository, gives a concrete, reproducible picture of where the two architectures diverge, and by how much, for your specific model and your specific usage pattern rather than for a generic one.

Why measured results matter more than marketing claims

The temptation in any vendor comparison is to reach for a single headline figure — "N times faster" — because it is easy to remember and easy to put on a slide. That number is almost always doing more work than it should. Performance is not one thing; it depends on the size of your model, the shape of your diagrams, the round-trip time of your specific network path, the number of concurrent users, and which operations your team actually performs most often. A headline multiplier measured on someone else's model, someone else's network, and someone else's workflow tells you very little about what you will experience on Tuesday afternoon in your own environment. The only number that means anything to you is the one measured against your repository, your network, and your team's actual usage pattern.

This is precisely why the honest recommendation is not to trust an architecture diagram, however sound the reasoning behind it, but to build the small benchmark harness described above and run it yourself, or to ask a vendor to run it with you and hand over the raw data rather than a summary slide. A dedicated benchmark methodology, applied consistently, is worth more than any comparison table a vendor produces about itself, and any vendor confident in their architecture should welcome that scrutiny rather than deflect it.

The honest limits of local-first performance

It would be dishonest to present local-first architecture as a performance silver bullet with no trade-offs, so it is worth being direct about what it does not fix. Moving the interactive path off the network does not make the network irrelevant; it relocates the network dependency to the synchronisation path, and if that path is starved of bandwidth for long enough, or offline for long enough, the shared workspace will fall behind the local reality until connectivity returns. A very large initial clone of a very large repository still has to move a great deal of data across whatever link is available, and no amount of local-first architecture changes the physics of that first transfer. Local speed also does not, by itself, solve the harder problem underneath multi-user modelling — reconciling two people's genuinely concurrent edits correctly — which is a separate engineering problem with its own separate answer, covered in depth elsewhere in this series.

There is also a genuine trade-off in where complexity lives. A traditional shared repository keeps the architecture simple by keeping everyone's reads and writes going through one place, at the cost of making every one of those reads and writes pay for the network. A local-first architecture removes that cost from the interactive path, but it does so by introducing a background synchronisation system that has to be engineered carefully, because getting reconciliation wrong is a far worse failure mode than a slow click. The performance argument for local-first is real and, in our own testing against representative round-trip times, substantial. But it is not free, and any vendor who tells you it is free — again, CelinQ included — has skipped the part of the story that actually required the engineering effort.

What local-first modelling buys you, concretely, is the removal of the network from the part of your day where a human is sitting and waiting: the click, the keystroke, the diagram opening under your cursor. That is where the hesitation lived, and that is the part of the architecture CelinQ was built to change. Whether the change matters as much for your team as it did in our own testing is a question worth answering with a stopwatch and a controlled network, on your model, not with a sales conversation.