Checks taking literally hours; add a timeout? #4301
Replies: 8 comments 4 replies
-
Can't we just add a timeout to fb itself and run it per family, rather than at a directory of many families, in such a case? Or just have a warning when the list of fonts fed to the main process is larger than 18? |
Beta Was this translation helpful? Give feedback.
-
I can take a look and see if the |
Beta Was this translation helpful? Give feedback.
-
I can fix that fairly easily. Need to shuffle some code around. Only one of the glyphs ( |
Beta Was this translation helpful? Give feedback.
-
Fix up in fonttools/fonttools#3300 |
Beta Was this translation helpful? Give feedback.
-
PR for speeding up saving: fonttools/fonttools#3301 For me, brings it down from 11s to 0.22s. |
Beta Was this translation helpful? Give feedback.
-
Same PR (fonttools/fonttools#3301) brings down instancing speed for me from 23s down to 0.36s. |
Beta Was this translation helpful? Give feedback.
-
Any plans to rewrite fontbakery using Rust? |
Beta Was this translation helpful? Give feedback.
-
This is all better now. |
Beta Was this translation helpful? Give feedback.
-
Fonts are getting more and more complex; things like Handjet, for example, have thousands of points and hundreds of masters.
We have a number of checks which decompile and recompile fonts (such as
hinting_stats
andvarfont/generate_static
) which take a ridiculously long time on Handjet; another check,interpolation_issues
, takes 11 hours on this font (I counted).The annoying thing is that these checks are not something we can optimise in Fontbakery; the underlying operations are all FontTools routines:
ttFont.save()
,mutator.instantiateVariableFont()
andvarLib.interpolatable.test
.Of course this is a pathological font, but we want to be able to deal with arbitrary fonts. It's no good if you throw a directory of fonts at fontbakery and come back six hours later to discover that your CI job has died and you got no output. I figure our options are:
I think (2) is possible but it would probably involve messing around with signal handlers and I don't know how well that would play with
-j
(and Windows). It's probably the lowest cost approach in the short term, but fonts will only get more complicated, and we will have to do (1) eventually.Beta Was this translation helpful? Give feedback.
All reactions