From: Randy MacLeod <randy.macleod@windriver.com>
To: alex.kanavin@gmail.com, Khem Raj <raj.khem@gmail.com>
Cc: openembedded-core@lists.openembedded.org,
Martin Jansa <martin.jansa@gmail.com>
Subject: Re: [OE-core] [PATCH v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags
Date: Tue, 14 May 2024 11:25:34 -0400 [thread overview]
Message-ID: <bccbb448-10d9-48e8-9b9a-72de5b7d9072@windriver.com> (raw)
In-Reply-To: <CANNYZj_dZEQgVtihxZ-PtiBHBB44OqMF7ebLKQTEg7Bt+rrJCw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]
On 2024-05-07 3:56 p.m., Alexander Kanavin via lists.openembedded.org wrote:
> On Tue, 7 May 2024 at 18:13, Khem Raj<raj.khem@gmail.com> wrote:
>> Firstly I am inclined towards removing it if we can, since I think it should be
>> packages to decide to use it, then they can maintain it better from testing POV,
>> However, there is something
>> to consider w.r.t. to this option. This does help in optimizing loading DSOs
>> by reducing the number of PLTs and improves loading time for DSOs which might
>> be quite meaningful for embedded devices that we target. However, we only
>> enable hidden visibility only for inlines so it won't be full benefits but we do
>> have better default compatibility.
>>
>> Since we have had this option for a long time and it still seems
>> relevant, I would
>> think it would make sense to do some benchmarking on a sizeable C++ program
>> perhaps chromium or webkit, and see the difference in DSOs sizes with
>> and without
>> this option and also benchmark the loading time of the resulting
>> chromium package.
>>
>> maybe we will find that the gains are not as significant, in that case
>> we might drop
>> it from defaults.
> I digged deeper and this is where I think it originated:
> https://git.openembedded.org/openembedded/commit/?id=ddd6d1fd26416a3766d754eeda4237a680a65520
>
> Ah the simpler times of oe-classic, when one could bundle four
> unrelated changes into one commit and explain none of them.
>
> Benchmarking I have no time for right now, just wanted to point out
> that adding the flag was never justified in commit log. Can you
> experiment with webkit?
I tried to build chromium with and without this flag but ran into build
problems - sigh.
I pulled out the next most-bloated single executable that I could think
of: nodejs
The bottom line is that the flag reduces the nodejs executable size by ~6%.
Actual sizes:
>>> 37333922 - 35245092
2088830
so 2 MB out of 37 MB !
Chromium has been updated over the weekend so I'll try that next.
What else would people like to see to assess the utility of this
compiler option?
../Randy
Original build:
❯ size
../chromium-poky-m-aab1335523/tmp/work/core2-64-poky-linux/nodejs/20.12.2/packages-split/nodejs/usr/bin/node
text data bss dec hex filename
35245092 628548 154792 36028432 225c010
../chromium-poky-m-aab1335523/tmp/work/core2-64-poky-linux/nodejs/20.12.2/packages-split/nodejs/usr/bin/node
With this patch:
❯ git diff
diff --git a/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb
b/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb
index d86c38f2f..50cff533f 100644
--- a/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb
+++ b/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb
@@ -42,6 +42,8 @@ S = "${WORKDIR}/node-v${PV}"
CVE_PRODUCT += "node.js"
+CXXFLAGS:remove = "-fvisibility-inlines-hidden"
+
# v8 errors out if you have set CCACHE
CCACHE = ""
❯ size
tmp/work/core2-64-poky-linux/nodejs/20.12.2/packages-split/nodejs/usr/bin/node
text data bss dec hex filename
37333922 628548 154792 38117262 2459f8e
tmp/work/core2-64-poky-linux/nodejs/20.12.2/packages-split/nodejs/usr/bin/node
❯ python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 35245092.0/37333922.0*100.0
94.40500786389386
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#199104):https://lists.openembedded.org/g/openembedded-core/message/199104
> Mute This Topic:https://lists.openembedded.org/mt/105955497/3616765
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
# Randy MacLeod
# Wind River Linux
[-- Attachment #2: Type: text/html, Size: 6578 bytes --]
next prev parent reply other threads:[~2024-05-14 15:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 5:33 [PATCH v2 01/11] rng-tools: ignore incompatible-pointer-types errors for now Khem Raj
2024-05-07 5:33 ` [PATCH v2 02/11] expect: ignore various issues now fatal with gcc-14 Khem Raj
2024-05-07 5:33 ` [PATCH v2 03/11] libunwind: " Khem Raj
2024-05-07 5:33 ` [PATCH v2 04/11] zip lrzsz connman-gnome libfm: ignore various issues " Khem Raj
2024-05-07 5:38 ` Martin Jansa
2024-05-07 5:57 ` Khem Raj
2024-05-07 5:33 ` [PATCH v2 05/11] p11-kit: ignore various issues fatal with gcc-14 (for 32bit MACHINEs) Khem Raj
2024-05-07 5:33 ` [PATCH v2 06/11] pcmanfm: Disable incompatible-pointer-types warning as error Khem Raj
2024-05-07 5:33 ` [PATCH v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags Khem Raj
2024-05-07 10:14 ` [OE-core] " Alexander Kanavin
2024-05-07 16:13 ` Khem Raj
2024-05-07 19:56 ` Alexander Kanavin
2024-05-07 20:37 ` Khem Raj
2024-05-14 15:25 ` Randy MacLeod [this message]
2024-05-14 15:43 ` Khem Raj
2024-05-14 15:53 ` Alexander Kanavin
2024-05-07 5:33 ` [PATCH v2 08/11] consolekit: Disable incompatible-pointer-types warning as error Khem Raj
2024-05-07 5:33 ` [PATCH v2 09/11] gtk4: Disable int-conversion " Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bccbb448-10d9-48e8-9b9a-72de5b7d9072@windriver.com \
--to=randy.macleod@windriver.com \
--cc=alex.kanavin@gmail.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).