Performance problem?

0 votes
asked Jul 22, 2017 in Bug by TiKu (120 points)


I'm using PlantUML on a Ubuntu Server 16.04 LTS with OpenJDK 1.8.0_131 (64 bit). PlantUML is the latest version. I call it like this:

java -jar plantuml.jar -tsvg -charset UTF-8 -o "/tmp" "/tmp/sample.uml"

I've uploaded sample.uml here. The CPU is an Intel Xeon L5520 (2 cores used, 2270 MHz). The machine has 4 GB of memory.
The call that I've posted above needs 17 seconds and uses both cores at 100%.
Is this considered normal performance or is there a problem?

For me it definitely is a problem, because the machine (a web server) hangs while PlantUML renders an image. On the same hardware with Ubuntu 14.04 and a much older version (probably from 2014) of PlantUML there have been no performance problems. But it might be that caching mechanisms have been better so that PlantUML has been called much less often - I can't verify this anymore as neither the machine nor the code around PlantUML still exist.

So is the performance of PlantUML fine and I should concentrate on the code around it?

T. Kunze

commented Nov 1, 2017 by Dusan
I have a similar performance issue on Windows. I'm using Windows 10 on system with 16Gb of RAM and an i7 CPU. I'm running the command as:

java -jar c:\dev\PlantUML\plantuml.jar -tsvg comp2.wsd

and it takes over 10sec to generate an svg file during which java process consumes over 1.7Gb of RAM. Input wsd file has 368 bytes and the output svg has 12Kb so the amount of time and memory used to generate the svg seems very excessive.

Are there any plans for fixing this?

Here is the file that is being processed:

:Send **str1**;
partition "str2" {
partition "str3" {
partition "str4" {
:Receive **str5**;
partition "str6" {
:Fetch str7;
partition "str8" {
:Use str9;
:Use str10;
:Use str11;
:Use str12;
:Use str13;
:Use str14;
:Use str15;
partition str16 {
:Validate str17;
:Generate event with str18;
partition str19 {
:Store str20;
:Publish str21;
commented Nov 1, 2017 by plantuml (257,900 points)
Thanks for your example, it really helps.
There is indeed a performance issue here.
It may be fixed in last beta:
Could you try and tell us ?
Thanks again!
commented Nov 1, 2017 by Dusan
Thanks for the quick response! I've tried the beta and for the time listed above the time got reduced from ~10sec to 3-4 sec. Process memory is still spiking to over 1Gb.

This is obviously a speed improvement, but I think that for the small files like the one I've listed above it should work instantly (far less than a second). Without something like that the process can not be used on a web server.
commented Nov 2, 2017 by plantuml (257,900 points)
With yet another beta (beta14), we are about 1-2 sec.
There are some other opportunities for performance improvement, but more complex to implement, so stay tuned!
commented Nov 2, 2017 by plantuml (257,900 points)
Ok, here is a last beta
We are about 0.5 second now.
We have used JProfiler ( really great product BTW!).
I think we won't be able to (easily) go faster than that, so I hope it's ok for you.
If you find other performance isssues (there are probably some), do not hesitate to post them!

1 Answer

0 votes
answered Nov 1, 2017 by plantuml (257,900 points)
@T. Kunze : Sorry about the delay...

Could you try with the last beta ( ) ?

It works fine with it for us.

commented Nov 4, 2017 by TiKu (120 points)
Yeap, now the time is down to 0,1-0,2 seconds. Thanks a lot!