Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119336
MIME-Version: 1.0
References: <Y8U9B4AVP/R7vazI@swift.blarg.de> <CAGBsUrdQAXE2qk_UDQY9v6pYpWH+=bX6S3ou+sttQamtDC1F9A@mail.gmail.com>
 <Y8VI5yanzli8D4Cm@swift.blarg.de> <alpine.DEB.2.23.453.2301181536160.23089@singlemalt.home.derickrethans.nl>
 <Y8gZWLQd1SvL6a3n@swift.blarg.de> <8DA390C5-5E67-4847-A89F-1A8CCC6C5389@gmail.com>
 <CAGBsUrcHNeMYC1bSUkRgp2YNWjQJFojBxw43gcy3dkzEZfF4wg@mail.gmail.com> <419f4c45-8171-1051-8956-175283fb6669@bastelstu.be>
In-Reply-To: <419f4c45-8171-1051-8956-175283fb6669@bastelstu.be>
Date: Wed, 18 Jan 2023 17:37:43 -0300
Message-ID: <CAAwFBqq5S2BC+_mYj42hpR5h9_NNcqWtvt6SyqXVF2rfkTBGng@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000077a7fa05f28fca55"
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: flaviohbatista@gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Heleno?=)

--00000000000077a7fa05f28fca55
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 18, 2023 at 4:17 PM Tim D=C3=BCsterhus <tim@bastelstu.be> wrote=
:

> Hi
>
> On 1/18/23 18:51, Kamil Tekiela wrote:
> > As you said yourself, this refactoring has no practical effect on
>
> It has no practical effect *yet*. The headers need to be untangled first
> before actual optimization can happen.
> > Or maybe have all
> > ZEND headers included with a single header?
>
> That would go against the goal of reducing compile times. Much of the
> time spent when compiling C is parsing megabytes of source code, because
> deeply nested and/or unnecessary includes will bloat the amount of code
> the toolchain will need to go through.
>
> Let me give a simple example:
>
> We have the following headers:
>
> a.h: 1 MB.
> b.h: Includes a.h and is itself 100 kB in size.
> c.h: Includes a.h and is itself 100 kB in size.
>
> foo.c: Includes b.h and c.h, but c.h is not actually used. Is itself 300
> kB in size.
>
> Now when compiling foo.c, a total of 2.5 MB of source code need to be
> parsed, because a.h is included twice. If the unused include for c.h is
> removed, then it will only be 1.4 MB in total. This multiplies quickly
> for more complex include chains. I'd like to point to this commit once
> more:
>
>
> https://github.com/haproxy/haproxy/commit/340ef2502eae2a37781e460d3590982=
c0e437fbd
>
> Removing two headers in a single file reduced the total compile by
> roughly 10%!
>
> Here's two more similar commits:
>
>
> https://github.com/haproxy/haproxy/commit/e5983ffb3adbf71a8f286094b1c1afc=
e6061d1f3
>
> https://github.com/haproxy/haproxy/commit/1db546eecd3982ffc1ea92c2f542a3b=
01ce43137
>
> Best regards
> Tim D=C3=BCsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Tim,

This may be a silly question, but in that case, wouldn't #ifdef guards keep
the compiler from including/parsing a.h twice?

When a.h is *not* required by any of b.h, c.h nor foo.c, I agree that it
should *not* be included at all, but when any of them,
or even if all of them requires it, the guards should be enough to avoid
redundant work afaik.

Or am I missing anything here?

--00000000000077a7fa05f28fca55--