Performance optimization of text-width computation

[kbrandwijk]

Currently, pdfkit is used for text width measurements. I would advise to use fontkit instead (it's also used internally by pdfkit), to cut down on the overhead and increase performance. See: https://github.com/devongovett/fontkit, method: font.layout().

[PyvesB]

Hey there, I could look into this, unless you would be interested in submitting a pull request? 😉

[kbrandwijk]

@PyvesB please do, I'm new to the project, and very limited in time.

[espadrine]

Thanks for the suggestion!

Personal testing makes me feel like pdfkit's overhead (ie, its word caching mechanism) over fontkit is mostly positive; calling fontkit directly changes the time spent in makeBadge from 0.461492ms to 0.563666ms average for the following benchmark:

node server 1111 >log &
sleep 2
for ((i=0;i<10000;i++)); do
  curl -s http://localhost:1111/badge/coverage-"$i"%-green.svg >/dev/null
done
kill $(jobs -p)
<log grep 'makeBadge total' | \
  grep -Eo '[0-9\.]+' | \
  awk '{s+=$1;n++} END {print s/n}'

If we tweak the benchmark to call /badge/coverage"$i"-"$i"%-green.svg to break the pdfkit cache, I get 0.360752ms, against 0.315269ms for fontkit.

[kbrandwijk]

Wow, I totally didn't expect that.

[paulmelnikow]

Continuation of #1377 (comment):

Something else we could think about here is multiprocess parallelism: basically doing the badge-width computation in one or more separate processes that don't block. That won't help with a sequential-test metric, but might help if we simulate a production-like load.

Also, and more simply, perhaps a bigger cache, or even a static cache, which contains precomputed widths for lots of common values, like in the example badge values, version numbers, and static badges we know we see a lot.

This might be a naive question: does kerning prevent us from computing the width character by character? Would it be possible to extract kerning rules from the font, so we could reimplement the computation in an even faster way?

[kbrandwijk]

With fontkit, and font.layout(), you get information for every glyph, including kerning info, so you could basically run that once, and store those values? That way text-width calculation becomes a static sum? You would have to cache that glyph info per font of course (is it even possible to use a different font with the hosted version, or is that always just Verdana?).

Also, what's wrong with just caching every value you ever come across? It's only text and a measurement, so it doesn't take up any space, even with potentially tens of thousands of entries.

[paulmelnikow]

@espadrine It looks like I need to add some logging code for the snippet in #1379 (comment) to work. What would I need to change?

I made a naive implementation and it seems to be working…

[espadrine]

@paulmelnikow Here's a diff:

diff --git a/server.js b/server.js
index 990c111..949322d 100644
--- a/server.js
+++ b/server.js
@@ -7468,7 +7468,9 @@ function(data, match, end, ask) {
     if (isValidStyle(data.style)) {
       badgeData.template = data.style;
     }
+    console.time('makeBadge total');
     const svg = makeBadge(badgeData);
+    console.timeEnd('makeBadge total');
     makeSend(format, ask.res, end)(svg);
   } catch(e) {
     log.error(e.stack);

You can add other console.time's for analysis' sake.

[espadrine]

basically doing the badge-width computation in one or more separate processes that don't block

Quick note: the OVH offer we are on, VPS SSD 1, has a single vcore.

https://www.ovh.com/us/vps/vps-ssd.xml

[paulmelnikow]

Quick note: the OVH offer we are on, VPS SSD 1, has a single vcore.

Ah, gotcha… thanks.

[paulmelnikow]

I opened #1390 with the approach I took.

[RedSparr0w]

Do you think this could be closed now that we have #1390 merged?
@paulmelnikow