Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119329 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 96583 invoked from network); 18 Jan 2023 19:17:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jan 2023 19:17:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5B88E180504 for ; Wed, 18 Jan 2023 11:17:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 18 Jan 2023 11:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1674069434; bh=ZaUx0htlPicPCvs+9hTaB9ZiemInSRfN97ucVZVuXyA=; h=Date:Subject:To:References:From:In-Reply-To:From; b=K6Qe+nv2dQkz5rl2AEKJTTV9UKaGs8b9SQ16W52m4PwDth9vFqgy7uN09DtZYPfLM KnqZgOPMHSxqM+BbwN3lDXv4vU+6v/3u9YYw5iodYBqe/zOyN21NXP7zCNGVlDwL1k OoFyrPB5m+LOjKaQ3od7f44naNgbPY4XPPiuaAVkYFh+FpT2kqPpVy66bRKLH0DpBe JDi5vtFXRkzFGPEpB21RT5KSFkM3JgFfnBrQZKUA/04GMVzVGp9oQXHgJRbkqFN7T9 7SDmqljE0WSdYFWvB9O4a0P/On/cNU3tOKHD7wo+L6AHl4m+j3Yf2dxQqTOtIxBGU8 5VBdSib16nAvw== Message-ID: <419f4c45-8171-1051-8956-175283fb6669@bastelstu.be> Date: Wed, 18 Jan 2023 20:17:13 +0100 MIME-Version: 1.0 Content-Language: en-US To: internals@lists.php.net References: <8DA390C5-5E67-4847-A89F-1A8CCC6C5389@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] RFC: rules for #include directives From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) 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/340ef2502eae2a37781e460d3590982c0e437fbd 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/e5983ffb3adbf71a8f286094b1c1afce6061d1f3 https://github.com/haproxy/haproxy/commit/1db546eecd3982ffc1ea92c2f542a3b01ce43137 Best regards Tim Düsterhus