GNU gettext - Bugs: bug #63641, Poor build parallelism in gettext
You are not allowed to post comments on this tracker with your current authentication level.
bug #63641: Poor build parallelism in gettext
Submitter: | Sergei Trofimovich <slyfox> | ||
Submitted: | Wed 11 Jan 2023 07:59:41 AM UTC | ||
Category: | Build | Severity: | 2 - Minor |
Item Group: | None | Status: | Wont Fix |
Privacy: | Public | Assigned to: | haible |
Open/Closed: | Closed |
Sun 12 Feb 2023 09:39:16 AM UTC, comment #2: |
Sergei Trofimovich <slyfox> |
Sun 12 Feb 2023 08:55:20 AM UTC, comment #1: This improvement is too costly for too little benefit.
|
Bruno Haible <haible>![]() ![]() |
Wed 11 Jan 2023 07:59:41 AM UTC, original submission:
I build gettext as part of fresh systems quite regularly (~daily). I noticed that gettext does not parallelize as good as it could. It is visibly slower than many other packages.
|
Sergei Trofimovich <slyfox> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Not to challenge your decision but to add a bit of color on current state: `gettext` builds 2m11s on my machine.
As it's an early package to build during system bootstrap it's slow build delays many other packages (with better parallelism) that depend on it.
To put `gettext` slowness in context: the whole of `coreutils` and it's tests builds 1m13s on my machine. And even `ocaml` (a language compiler with it's own code generator) takes 1m45s.
I find it hard to believe gettext does as much useful work as these packages during the build be it time measurement or energy consumption. Or be it per-core measurement vs whole machine load.