This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR52977


Diego Novillo <dnovillo@google.com> a Ãcrit:

> On Mon, Apr 16, 2012 at 10:23, Richard Guenther <rguenther@suse.de> wrote:

[...]

>> I'm not sure PPH will replace PCH - will it?

[...]

> In theory, it may.  But it's not in the immediate plans.
>
> The big thing that PCH has going for it is load speed.  PCH is almost
> instantaneous, PPH isn't.  A 1Gb PCH file can be restored in <1s, the
> corresponding PPH file needs ~8s to restore.  The implementation can
> still be tuned for performance, but it will never be as fast as a
> couple of mmap operations.
>
> PPH is a much smaller representation (that 1Gb PCH file can be
> represented in <400Mb in PPH) and more flexible (almost any arbitrary
> subset of headers can be turned into separate PPH images).
>
> So, it's not clear whether we will want to replace PCH with PPH.
> Flexibility costs raw performance.  If the performance gap can be
> bridged, we may want to consider it in the future.

I guess it's also worth noting one limitation of PPHs that is, if I
believe the wiki:

    In essence, the only headers that can be pre-parsed are those that
    produce the same result when they are compiled in isolation or as
    part of another translation unit. So, header files that are affected
    by pre-processor symbols defined before inclusion are not going to
    be considered (e.g., stddef.h).

[1]: http://gcc.gnu.org/wiki/pph#Scope_and_limitations

How hard would it be to drop that limitation?

-- 
		Dodji


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]