ICU in Haiku

We need to know what we are using from the ICU, so we can look for alternatives or use .dat files from the ICU.

Using a rust application will cause more bloating and require a lot of extra work.

I believe the best solution is to identify how we use the ICU, use Haiku’s native software to test, make a comparison with the .dat file, using ICU and other software together, for example libgrapheme, so we can define a path.

Using rust will create new problems and will not solve the problem of memory consumption and bloated executables!

Look: Release glaucus-s6-x86-64-v3-20230428 · glaucuslinux/glaucus · GitHub

We need to see our needs and see what is good or replicate it in our own way, not follow trends or bad codes and Linux practices.

1 Like

Rust memory consumption should be about the same as C / C++ and will depend largely on the algorithms and data structures chosen it has very little overhead of its own.

As far as new problems it creates, I’m not aware of any major issues, and the link you provided seems to me like it is mainly down to preference of the developer. If they want a language they are a bit more used to over one that ensures memory safety that is their prerogative.

Rust would initially consume the same amount of memory, but due to implementation in the system, it will consume more memory and resources.

There are some projects replacing ICU with libgrapheme, it’s interesting to see the source code.

Flutter is investigating usage and SKIA is implementing patches:

Implementation in imv, ”Add support for libgrapheme as an icu replacement”:

https://lists.sr.ht/~exec64/imv-devel/patches/27165

Why do you think that?

See the answer of Pulkomandy here: https://discuss.haiku-os.org/t/icu-in-haiku/15146/53

These links provide detailed step-by-step instructions on how to use rust and problems, even if you know the code, rust creates more problems than solutions:

"“Here’s a well documented case study by devs.”

https://www.reddit.com/r/linux/comments/wwsiaf/writing_a_wayland_compositor_is_much_harder_than/

These 2 tickets show the idea of ​​integration with ICU, we can use an alternative to ICU:

https://dev.haiku-os.org/ticket/12802

https://dev.haiku-os.org/ticket/12803

https://dev.haiku-os.org/ticket/18302

https://dev.haiku-os.org/ticket/14791

1 Like

https://dev.haiku-os.org/ticket/17737

NOTE: I’m not saying that removing ICU makes that much sense, just that it’s always important to consider what bulk/bloat is added in terms of software dependencies.


Because if you simply add 30 MB here and there just whenever, then eventually that will begin to add up to a non-trivial amount of storage/ram used. After a hundred such decisions, we would now be talking about around 3000 MB (round up to 3 GB if it helps you understand).

Just because it isn’t 1985 doesn’t mean we’re all okay with developers wasting our hardware resources needlessly.

I, for one, very much dislike how modern versions of Windows try to use all of my memory at all times, without any respect to the my priorities. That choice of behavior allows most web browsers to just eat as much as they feel like or happening to be leaking.

Storage space is less critical, but it can become a problem with time. Anyone who plays Steam games knows that there is ultimately an upper limit on what you can have installed.

4 Likes

Yes there is that point, but as I pointed out previously runtime overhead per application is different between implementations.

Rust could be lower after you have a heavy application open even though you have the overhead of two libraries. Benchmarking required though…

Through the source code, which ICU interacts with Haiku, a possible solution to reduce memory consumption and size of executables comes from here or replacing some part of the code with another alternative to ICU:

https://cgit.haiku-os.org/haiku/tree/src/system/libroot/add-ons/icu

1 Like