[PATCH] pci: Add include guard to include/linux/pci_ids.h

[PATCH] pci: Add include guard to include/linux/pci_ids.h

[Rasmus Villemoes]

Adding an include guard frees the preprocessor from reparsing over
2600 #defines in the cases where pci_ids.h is somehow included more
than once. This gives a tiny-but-measurable performance improvement
when compiling such files.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 include/linux/pci_ids.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 7fa3173..6ed0bb7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -6,6 +6,8 @@
  *	Do not add new entries to this file unless the definitions
  *	are shared between multiple drivers.
  */
+#ifndef _LINUX_PCI_IDS_H
+#define _LINUX_PCI_IDS_H
 
 /* Device classes and subclasses */
 
@@ -2968,3 +2970,5 @@
 #define PCI_DEVICE_ID_XEN_PLATFORM	0x0001
 
 #define PCI_VENDOR_ID_OCZ		0x1b85
+
+#endif /* _LINUX_PCI_IDS_H */
-- 
1.9.2

Re: [PATCH] pci: Add include guard to include/linux/pci_ids.h

[Bjorn Helgaas]

On Thu, Jul 10, 2014 at 02:05:11PM +0200, Rasmus Villemoes wrote:
> Adding an include guard frees the preprocessor from reparsing over
> 2600 #defines in the cases where pci_ids.h is somehow included more
> than once. This gives a tiny-but-measurable performance improvement
> when compiling such files.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Applied to pci/misc for v3.17, thanks!

> ---
>  include/linux/pci_ids.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 7fa3173..6ed0bb7 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -6,6 +6,8 @@
>   *	Do not add new entries to this file unless the definitions
>   *	are shared between multiple drivers.
>   */
> +#ifndef _LINUX_PCI_IDS_H
> +#define _LINUX_PCI_IDS_H
>  
>  /* Device classes and subclasses */
>  
> @@ -2968,3 +2970,5 @@
>  #define PCI_DEVICE_ID_XEN_PLATFORM	0x0001
>  
>  #define PCI_VENDOR_ID_OCZ		0x1b85
> +
> +#endif /* _LINUX_PCI_IDS_H */
> -- 
> 1.9.2
> 

Re: [PATCH] pci: Add include guard to include/linux/pci_ids.h

[Rasmus Villemoes]

Bjorn Helgaas <bhelgaas@google.com> writes:

> On Thu, Jul 10, 2014 at 02:05:11PM +0200, Rasmus Villemoes wrote:
>> Adding an include guard frees the preprocessor from reparsing over
>> 2600 #defines in the cases where pci_ids.h is somehow included more
>> than once. This gives a tiny-but-measurable performance improvement
>> when compiling such files.
>> 
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>
> Applied to pci/misc for v3.17, thanks!
>

Great.

One thing I thought about, but which is likely undoable in practice:
There are only about 800 files which use any of the #defines in
pci_ids.h, but more than 3000 files include pci.h directly or
indirectly. Making those 800 include pci_ids.h directly and removing it
from pci.h could speed up compilation of the other 2200.

Rasmus

Re: [PATCH] pci: Add include guard to include/linux/pci_ids.h

[Bjorn Helgaas]

On Sat, Jul 12, 2014 at 6:09 AM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> Bjorn Helgaas <bhelgaas@google.com> writes:
>
>> On Thu, Jul 10, 2014 at 02:05:11PM +0200, Rasmus Villemoes wrote:
>>> Adding an include guard frees the preprocessor from reparsing over
>>> 2600 #defines in the cases where pci_ids.h is somehow included more
>>> than once. This gives a tiny-but-measurable performance improvement
>>> when compiling such files.
>>>
>>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>>
>> Applied to pci/misc for v3.17, thanks!
>>
>
> Great.
>
> One thing I thought about, but which is likely undoable in practice:
> There are only about 800 files which use any of the #defines in
> pci_ids.h, but more than 3000 files include pci.h directly or
> indirectly. Making those 800 include pci_ids.h directly and removing it
> from pci.h could speed up compilation of the other 2200.

Yeah, changing 800 files for a minor build performance improvement
doesn't sound like it'd be worth the churn.

Bjorn