[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <da520d6fa03c4645a28e5f4fae013d35@AcuMS.aculab.com>
Date: Mon, 14 Aug 2023 08:12:55 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andy Shevchenko' <andriy.shevchenko@...ux.intel.com>
CC: 'Petr Mladek' <pmladek@...e.com>, Marco Elver <elver@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Steven Rostedt <rostedt@...dmis.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
"Sergey Senozhatsky" <senozhatsky@...omium.org>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends
From: Andy Shevchenko
> Sent: 10 August 2023 14:14
>
> On Wed, Aug 09, 2023 at 08:48:54AM +0000, David Laight wrote:
> > ...
> > > If you split headers into so many small pieces then all
> > > source files will start with 3 screens of includes. I do not see
> > > how this helps with maintainability.
> >
> > You also slow down compilations.
>
> Ingo's patches showed the opposite. Do you have actual try and numbers?
The compiler has to open the extra file on every compile.
If you include it from lots of different places it has to open
it for each one (to find the include guard).
Any attempted compiler optimisations have the same much the
same problem as #pragma once.
With a long -I list even finding the file can take a while.
Probably most obvious when using NFS mounted filesystems.
Especially the 'traditional' NFS protocol that required a
message 'round trip' for each element of the directory path.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists