Precompiling and Embedding Resources for Performance Optimization about fluent-rs HOT 2 CLOSED

I think this is already largely covered, just a few notes:

• Speed of the parser is basically a non issue here. Speed has already been (and still is) prioritized so much that the cost of parsing is not a driving force to need to refactor your application.
• A more likely need is to bundle/embed assets not for speed so much as just to have them bundled. There are many different approaches that can be taken for that, and they are already supported. For example I use rust-embed to bundle assets. For some of them I embed all locales and parse them all at run time, others select and parse only the necessary locales, and others cache parsed and serialized data.
• These crates are fairly low level building blocks, while any specific implementation of asset handling would be a rather higher level thing. Given that most projects probably embed other kinds of assets too, I think it's best to leave this to other crates. In fact there are already quite a few. Besides using other low level building blocks like rust-embeded there are much higher level crates like i18n-embeded that combine both Fluent and embedded building blocks, not to mention several others like it.

If there is something that can be done to make interfaces more ergonomic so that higher level crates can better facilitate this kind of thing we'd be happy to consider it and consider contributions, but I think we can say that directly adding a precompile/embedding system into these crates is out of scope.

from fluent-rs.

Hi, this is largely dependent on your project, but I'd like to stress that Fluent parsing is very fast. You can run cargo bench on your own but on a regular laptop (cd fluent-bundle; cargo bench), but here's some back of a napkin calculations:

parsing and resolving 500 messages in a single file takes about 16 microseconds on my laptop.

To put this in a perspective, to achieve 60fps framerate, you need each frame to take less than 16 milliseconds.

You can parse and resolve 500 fluent messages one thousand times each and every frame to deplete this budget.

Now, of course you wouldn't want to do that, but since runtime language change/reload happens very rarely, you are very unlikely to exceed even a single frame budget this way.
You need to look downstream at your stack, what else is involved? Constructing translated UI tree, layout, etc. those also take time. Caching translated UI tree may be a win, at the cost of having to implement cache invalidation etc.
All I'm saying here is that I doubt that even on a very slow mobile phone parsing and resolution of fluent messages costs enough to build infra to avoid. YMMV

from fluent-rs.