Re: Can we refactor output-svg.scm to avoid regexp?

[K.L.]

Glad to hear that.

And I have a good news. Today I tried making hash tables to cache regex
results in guile source (code
<https://gitlab.com/k.l.lambda/lilypond/-/blob/dev/kl/cached-regex/node-addon/android/third-party/libs/guile/src/regex-cached.cc>).
As my test results, the cache hit rate is more than 96.5% for a fairly
large music score. And also the time cost is reduced to about 1/30 of
origin. So now I'm more confirmed about this regex issue's importance.
Though hash cache is not the final solution, by this workaround, web apps
based on Lilypond (like hacklily <https://www.hacklily.org/>) will gain
more feasibility now.

On Thu, Oct 29, 2020 at 10:38 AM Étienne Beaulé <beauleetienne0@gmail.com>
wrote:

> Svg-woff is not only broken with that old bug, but also that SVG fonts are
> deprecated. The hope is that the work on SMUFL done this summer could be
> used in the SVG backend, and with that, embedding musical symbols directly
> could be avoided to reduce regex use.
>
> Étienne
>
> > Le 28 oct. 2020 à 22:27, K.L. <k.l.lambda@gmail.com> a écrit :
> >
> > Hello guys.
> >
> > I ran a profiling for SVG backend engraving, I saw the most time cost
> > (95%+) is taken by regexp execution.
> >
> > It seems the usage of regexps in output-svg.scm is to extract vector font
> > content fragments from font svg assets. Can we refactor this work by an
> XML
> > parser, maybe in C++?
> >
> > I saw there is another alternate option, svg-woff. But I encountered the
> > scm error:
> >
> >> output-svg.scm:448:16: Unbound variable: paper
> >>
> >
> > It seems an unresolved old bug for some years after googling it.
> >
> > This may be the biggest performance bottleneck of SVG backend at present,
> > once fixed, we will get huge improvement.
> >
> > Any ideas?
> >
> > [image: image.png]
> > [image: image.png]
> > <image.png><image.png>
>
>