RazrFalcon
commented
3 years ago rustybuzz already has some rudimentary benchmarking. So you can just extend that one.
As for Criterion, I think rust-bench is enough for now.
I haven't tested memory usage, but it should be similar to harfbuzz. We're not allocating much of data. most of the parsing is allocation free.
Size overhead is a bit harder, because hb has a lot of optional dependencies and also includes subsettings, so I'm not sure how to compare them.
As for benchmarks todo:
- Variable fonts. ttf-parser doesn't support so called phantom points, which makes bbox calculation slower than in harfbuzz. But this is fairly obscure feature, since most fonts have precalculated bboxes.
- Different scripts testing. Currently we're testing only Latin and Arabic.
- AAT layout. Currently, we're testing only OT.
But to write such benchmarks you really have to know what you're doing. So it requires some knowledge about TrueType and shaping.
On the other hand, if you have some specific use case and rustybuzz is slower, bigger or whatever in it - feel free to open an issue.
cryptoquick
Congrats on publishing the recent release! I know how hard it is to push something over the finish line. I'm incredibly curious, however, I don't suppose you've observed any differences in binary size (wasm and native), speed, or memory usage, compared to harfbuzz? That could have broader implications, such as for the harfbuzzjs project, as well as obviating the necessity for projects to depend on harfbuzz-sys... And could have even broader implications still.
Such a benchmark could be important for making such a case on those projects and others, including those in the future, even if it shows promise in just one of those metrics, and bringing attention and broader open source utility to this project so as to reduce your workload as maintainer.
Should this work not show promise on any of these fronts, such an effort could serve as a "guiding star" for performance optimization efforts.
I could look into benchmarking, if you like. Size comparisons should be somewhat trivial, although the project would need to have some Cargo.toml compilation flag noodling done for optimizing for size, if that's so desired, and the benchmark would only be for the subset of features implemented here, of course, and not obviating the necessity of some current users of harfbuzz beyond the present feature set... Yet. (Again, I'm sure many would share my curiosity)
Some questions that will need answers: