Ultralightweigth version of Verovio ?

[efreja]

Hello,

Would it be possible to release with all Verovio version deliverables, an ultralightweight, green IT version of Verovio that suits to situations where only very simple and short music fragments needs to be rendered, thus increasing greatly the speed of first page load ?

Indeed, at first page load, the js is downloaded and on small devices like old smartphones, it can lead to a dissuasive waiting time.

In figures : Today version 3.9.0 (verovio-toolkit-light.js), even if it has lost weigth recently, is still 7.8Mb, which is about 1.8/1.9Mb transferred (as zipped), for a content download duration of about half a second.

This js is very heavy in comparison of most of all js downloaded. As an example jQuery is 87K (30k transferred).

Would it be possible to release a version just supporting CMN features, no neumes, no PAE, no MXL, no HUMDRUM, etc … ?

I've looked at the documentation and found that some compilation switches could be used for that, so maybe using:

• NO_PAE_SUPPORT=ON
• NO_MXL_SUPPORT=ON
• NO_HUMDRUM_SUPPORT=ON

would decrease its size.

But there may be other switches also, and I don't figure out exactly what would be the right scope of a featured-reduced version that however would suit to a maximum of such usages..

Thanks

[ahankinson]

You can experiment with this by using the buildToolkit command: https://github.com/rism-digital/verovio/blob/develop/emscripten/buildToolkit

That allows you to set all the options, and you can see which ones make the most difference in the output. From previous experiments it wasn't the input format switches that took the biggest chunk -- there is an overhead that emscripten brings in, and the embedded fonts and other data add quite a bit as well.

[efreja]

Thanks, good point concerning the fonts! I guess a single font would be enough for such minified version.. I could indeed try to compile it but for the moment my mac is at the end of the road, ....
But I wanted to raise that issue on purpose to find what would be the good things to take out of such release with a general community approval, and also more experienced 'builders' that could tweak these compilation switches to see how it impacts the final js size..

[ahankinson]

./buildToolkit -l -D -H -P -X -- build a light version, disable DARMS, Humdrum, PAE, and MusicXML. This results in a .gz file at 1.6MB.

.rw-r--r-- nobody staff 7.0 MB Wed Apr 13 15:55:01 2022 verovio-toolkit-light.js
.rw-r--r-- nobody staff 1.6 MB Wed Apr 13 15:55:01 2022 verovio-toolkit-light.js.gz

[ahankinson]

./buildToolkit -M -l -x "Gootville,Bravura,Petaluma" -D -H -P -X gets it down to 5.9MB / 1.3MB (the fonts compress quite well).

I think if you're looking for a sub-100kb build, it's not really possible. Even sub-1MB would be really bare-bones (you could build a custom font with only the symbols you need).

[efreja]

Well, 5.9 against 7.8, that's a gain of about 25%! A great start! However, personnally I think support of MusicXML should be kept (but not MXL, though). And I don't know if there's a switch for non CWMN notation like Neumes and how much it counts for..
In any case, whatever the exclusions that are made, I think an agreement should be found in the community so that it can be released as standard and used by as many people as possible...

[efreja]

BTW there's also Leland font to get rid of in that case...

[rettinghaus]

There's also abc import that could be disabled. Furthermore we could probably disable the miniz code if no compressed MusicXML should be added, but that will not help much.

[craigsapp]

This js is very heavy in comparison of most of all js downloaded. As an example jQuery is 87K (30k transferred).

jQuery does not typeset music 😵‍💫 (nor is it compiled from C++, which has an initial overhead).

And I don't know if there's a switch for non CWMN notation like Neumes

That is a good idea (it could also limit the font size a tiny bit), but it is unlikely to be possible since neumes/mensural and CMN notations are mixed in the code in a way that is probably difficult to separate. (Currently only one of mensural or CMN can be shown at the same time, however, so there is some organization in the code to treat these independently)

the fonts compress quite well

I was checking them a few years ago and they were each adding about 100 kB to the js file.

Furthermore we could probably disable the miniz code if no compressed MusicXML should be added, but that will not help much.

Yes, but that should probably be disabled in tandem with disabling MusicXML (unless it is useful for woking with compressed MEI files).

[lpugin]

It makes sense to have only the Leipzig font for the light version. We can change this. BTW, -light was a bad choice. It refers actually to the memory allocation. It is meant to be used in cases where only small scores are being processed. In any case, having only one font for that version does seem like a good idea.

Unfortunately, as we can see already, it would be very difficult to reduce significantly the result size. I understand the argument, and I did look at it already in the past, but I do not think an ultra small version (meaning a result of a around 2MB) would be easily feasible.

I am not keen to have the code polluted (sorry for the word) with #ifdef / #endif everywhere only to gain a few hundreds kB, or maximum a few MB. However, @efreja if you want to dig into this and can come up with a solution which is not adding preprocessor instructions everywhere, we should certainly consider it.

(For the record, the size of the codebase is:

• ./src 7.4 MB
• ./include 2.4 MB
• ./libmei 1.4 MB

I will agree that C++ is more verbose than JavaScript, but the same code in JavaScript would probably not be much less than 80% of that.)

[ahankinson]

There are also a few options to experiment with for code size in the emscripten configuration:

https://emscripten.org/docs/optimizing/Optimizing-Code.html#code-size

This might also help:

https://floooh.github.io/2016/08/27/asmjs-diet.html

[efreja]

@lpugin I don't know what to say, I'm just suggesting and I wouldn't be surprised that some code is not ready to be separated between parts that could be excluded and parts that should remain as part of such 'core' version (example of CWMN & neumes).
I fully understand that it would need digging into this and not knowing the code I wouldn't know at first sight how to avoid conditional compilation in such cases.. But my concern is to know if you think this is a good idea, and that some work may be done in the future on this. Footprint is very important in these days of green it and it's useless that people download 7,8Mb if the strict functionalities they need fit into 20% of that size.. After all that's again the Pareto law ;-)
I really think such version should be useful and attractive to render small and simple scores at lightspeed.
At last, I'm not willing to open the box of the code myself, I have no time for that even though I really think Verovio is a great project!

[lpugin]

Thanks for bringing the idea. It seems that there is a consensus that we can remove a few more things from the -light version of toolkit. We should do it. But otherwise, as you can see, the emscripten build is already pretty much optimized and there is unfortunately no straightforward way to reduce the size of the JS code drastically. I do not expect work to be done on this specifically. However, as always, we will keep an eye on its size and make sure it remains in the same scope.

[samuelbradshaw]

It's hard to know exactly what to remove that would be useful for most users who want a smaller version. For example, I don't need PAE, ABC, or Humdrum, but I need MusicXML and MXL.

I don't know a lot about how emscripten works, but is there a way to separate the JavaScript toolkit into multiple files? That would allow a web developer to choose which features they want to reference (for example, MEI rendering and MusicXML conversion, but not PAE or Humdrum), without having to recompile or build the toolkit themselves.

[ahankinson]

If you compare it to even Vexflow, which less capable but written in "raw" JS, that's still at 800kb. And most music notation systems can run into the 10s, if not 100s of MB. (Lilypond comes to mind).

I think we also need to consider that smaller size != more efficient code. If your goal is to be more energy efficient, you need to look at how much power is used over all operations, not just downloads.

Quite a few common optimizations can actually increase the download size of the executable, meaning reducing the size can make the code less efficient to run (e.g., unrolling loops, or inlining function values). Most browsers will cache assets and not re-download them if they don't need to, so while optimizations that increase the size make it slower on the first load, it will be much faster (and energy efficient) with every subsequent interaction.

I'm not saying we shouldn't look at optimizing the download size, but if our goal is actually energy efficiency, we should look at that specifically, rather than only download size.

If you wanted to poke around, the code in the buildToolkit script is quite easy to understand and modify.

[lpugin]

Obviously if we can find ways to reduce the executable size that is always welcome. On the emscripten side, we have -O3 with DNDEBUG enabled. Last time I looked at optimizing the size it was by far the best options. But that was a while ago, and if anybody wants to look again and see if we can adjust it, that would be excellent.

@samuelbradshaw there might be ways to split it is different files. But that means probably having dynamic loading/linking. I am not sure how easily that would work in a code base like the one we have. It is certainly not straight forward and would be over the top in my opinion.

[efreja]

Thanks for the comments. Probably the idea must continue to make its way to find the ideal arbitration on the reduction of the functionalities. I think it may save more space and be safer than applying agressive -O3 optimizations that in my experience may produce wrong code (and sometimes not obvious to detect, unless you have very good regression tests).

[lpugin]

Thanks for the comments. Probably the idea must continue to make its way to find the ideal arbitration on the reduction of the functionalities.

OK, we can move it to the backburner.

I think it may save more space and be safer than applying agressive -O3 optimizations that in my experience may produce wrong code (and sometimes not obvious to detect, unless you have very good regression tests).

From my experience, O3 and O2 will produce about the same size with Verovio. This might be different with another codebase, but that is what I noticed. I never encountered "wrong code" problems, but if you did, please open an issue for that. We should definitely look at it. And if you want to contribute regression tests for this, that would be great too!

Not using O2 or O3 optimization does not look very bright since the size of the results matters, also for users interested to have the full functionalities. Switching to O1 produces a 17.7MB file.