Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Headers are Expensive

virtuallyrandom.com

Post reply on HN
Print view View original

71–80 of 115 posts

Re: C++ Headers are Expensive

#71

Post by AdieuToLogic »

srean wrote: post #51
nanolith wrote: post #40

Earlier quoted context omitted.

Right. Much like avoiding pImpl because it might make a function call that occurs 0.001% of the time faster. That is the basis of the thread I was replying to. Understanding what you are optimizing FOR and where the most attention should be spent is the crux of Knuth's argument. Trying to be clever up-front is often counter-productive. There is nothing wrong with making some architectural decisions up front, but that…

Well pImpl itself could be a premature optimization.

The "pimpl idiom"[0] is about insulation, not optimization. What it affords is ensuring collaborators have no knowledge of a type's implementation details (data as well as private methods), which also has the byproduct of allowing for faster compilation times.

HTH

0 - https://cpppatterns.com/patterns/pimpl.html

Re: C++ Headers are Expensive

#72

Post by vbezhenar »

kccqzy wrote: post #24
shereadsthenews wrote: post #9

Earlier quoted context omitted.

pImpl pattern is great for those who don’t care about performance but it’s inappropriate for most header libraries. You wouldn’t want a library that hides the implementation of std::vector for example. With a visible implementation the compiler compile e.g. operator[] down one x86 instruction. With a pImpl pattern it will be an indirect function call in all likelihood that will be hundreds of times slower. It can mak…

Using the pimpl pattern doesn't mean an indirect function call. The function to be called is always known. It's just an extra indirection in the data member. It's cheap. Think of it as Java style memory layout: everything that's not primitive stored in an object is a reference and therefore behind one level of indirection. The performance of Java is acceptance in the vast majority of use cases. Using pimpl will be th…

Java JIT-compiler inlines short method calls whenever possible. Though C++ compiler should be able to do the same.

Re: C++ Headers are Expensive

#73

Post by yuushi »

repsilat wrote: post #50
Someone wrote: post #31

Earlier quoted context omitted.

”It's just an extra indirection in the data member. It's cheap” That extra indirection often means a cache miss. That isn’t cheap. Accessing each item traversed through a pointer can easily halve program speed. Java tries hard to prevent the indirections (local objects may live in the stack, their memory layout need not follow what the source code say, objects may even only exist in cpu registers)

Hmm... if you were a horrible person you could declare a `char[n]` member instead of a pointer. Then you could placement-new the impl in the constructor, and static-assert that `sizeof(impl)>=n`... No more cache misses :-). :-(

This doesn't take into account the alignment of the type though (you'd want to use std::aligned_storage), but that requires knowing enough about T to be able to use sizeof() and alignof(), which means no incomplete types, bringing us back to where we started.

Re: C++ Headers are Expensive

#74

Post by blt »

beached_whale wrote: post #63
ChrisSD wrote: post #39

Earlier quoted context omitted.

This is why the rule of zero advocates are getting louder.

Rule of zero classes are awesome. It forces a separation of concerns too, generally a good thing :), as the handling of special things is done by a class that does that(e.g. unique_ptr, vector...) and your class describes only what is in it and how to interact with it. But no more detailed than that.

Totally agree. Recently used unique_ptr with a custom deleter is to consume a C library that requires heap allocation with its own alloc/free functions. No destructor!

Re: C++ Headers are Expensive

#75

Post by Gupie »

nanolith wrote: post #4

I recommend three things for wrangling compile times in C++: precompiled headers, using forward headers when possible (e.g. ios_fwd and friends), and implementing an aggressive compiler firewall strategy when not. The compiler firewall strategy works fairly well in C++11 and even better in C++14. Create a public interface with minimal dependencies, and encapsulate the details for this interface in a pImpl (pointer to…

Any advise for reducing link times?

Re: C++ Headers are Expensive

#76

Post by Valmar »

lbrandy wrote: post #23

All of msvc, gcc, clang, and the isocpp committee have active work ongoing for C++ modules. We'll have them Soon™.

Who knows whether they'll see much use, due to C++ needing to keep backwards compatibility for older projects that demand older versions of C++.

It probably partially depends on whether old-style headers can be used simultaneously with new-style modules.

Re: C++ Headers are Expensive

#77

Post by pjmlp »

AndyKelley wrote: post #14

In the Zig stage1 compiler (written in C++), I tried to limit all the C++ headers to as few files as possible. Not counting vendored dependencies, the compiler builds in 24 seconds using a single core on my laptop. It's because of tricks like this: /* * The point of this file is to contain all the LLVM C++ API interaction so that: * 1. The compile time of other files is kept under control. * 2. Provide a C interface…

Any plans to actually bootstrap the compiler?

Re: C++ Headers are Expensive

#78

Post by pjmlp »

nanolith wrote: post #4

I recommend three things for wrangling compile times in C++: precompiled headers, using forward headers when possible (e.g. ios_fwd and friends), and implementing an aggressive compiler firewall strategy when not. The compiler firewall strategy works fairly well in C++11 and even better in C++14. Create a public interface with minimal dependencies, and encapsulate the details for this interface in a pImpl (pointer to…

Additionally, actually make use of binary libraries across modules, and extern templates for common type parameters.

Re: C++ Headers are Expensive

#79

Post by pjmlp »

vbezhenar wrote: post #72
kccqzy wrote: post #24

Earlier quoted context omitted.

Using the pimpl pattern doesn't mean an indirect function call. The function to be called is always known. It's just an extra indirection in the data member. It's cheap. Think of it as Java style memory layout: everything that's not primitive stored in an object is a reference and therefore behind one level of indirection. The performance of Java is acceptance in the vast majority of use cases. Using pimpl will be th…

Java JIT-compiler inlines short method calls whenever possible. Though C++ compiler should be able to do the same.

And they do, when given PGO data, or when doing LTO.

Re: C++ Headers are Expensive

#80

Post by pjmlp »

branchless wrote: post #43
kccqzy wrote: post #24

Earlier quoted context omitted.

Using the pimpl pattern doesn't mean an indirect function call. The function to be called is always known. It's just an extra indirection in the data member. It's cheap. Think of it as Java style memory layout: everything that's not primitive stored in an object is a reference and therefore behind one level of indirection. The performance of Java is acceptance in the vast majority of use cases. Using pimpl will be th…

The only advantage of c++ is max perf. If we could skip a beat we couldn't justify using c++.

It is still wins in "portability + expressiveness + safer than C" areas.

There are still more platforms with a C++ compiler available than Ada, Java or C# ones, let alone Go, D, Rust, Swift.

So if the goal is to make the code available to all platforms, without having to deal with C's lack of safety, then C++ it is.

Post reply on HN