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

21–30 of 115 posts

Re: C++ Headers are Expensive

#21

Post by beached_whale »

nanolith wrote: post #13
beached_whale wrote: post #12

Earlier quoted context omitted.

One hickup is that with unique_ptr you now have a rule of 5 thing, you need to declare a destructor which means you need to declar the copy/move constructor and assignment too. Not usually a big deal, but is extra code.

This is true. Fortunately, these do not need to be inlined, which can still free client code of compile time overhead. It's a tradeoff between compile time and complexity.

Another option is something like pimp but keep the state in the public class. Now you get stack allocation but the private part is still private and firewalling all the other headers and details not needed for the public interface. Just pass this to the private methods.

Edit: Something like https://github.com/beached/stack_pimpl

Re: C++ Headers are Expensive

#22

Post by nikanj »

nanolith wrote: post #18
shereadsthenews wrote: post #16

Earlier quoted context omitted.

That only makes sense if you are planning to offer two implementations of your library. Which I of course urge you to not do. This article is about the STL headers. The reason std::sort beats the pants off all other languages’ sort routines is because the iterators of every collection, all specializations of swap, and the comparator can all be visible to the compiler. If they weren’t, it would be a lot slower. Premat…

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

Knuth wasn't saying "just ignore performance altogether", he was saying "stop making things needlessly complicated for the last bit of juice".

Re: C++ Headers are Expensive

#24

Post by kccqzy »

shereadsthenews wrote: post #9
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…

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 the same.

Re: C++ Headers are Expensive

#25

Post by erubin »

nanolith wrote: post #18
shereadsthenews wrote: post #16

Earlier quoted context omitted.

That only makes sense if you are planning to offer two implementations of your library. Which I of course urge you to not do. This article is about the STL headers. The reason std::sort beats the pants off all other languages’ sort routines is because the iterators of every collection, all specializations of swap, and the comparator can all be visible to the compiler. If they weren’t, it would be a lot slower. Premat…

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is

Re: C++ Headers are Expensive

#26

Post by loeg »

RcouF1uZ4gsC wrote: post #15

> The test was done with the source code and includes on a regular hard drive, not an SSD. In my opinion, this makes any conclusion dubious. If you really care about compile times in C++, step 0 is to make sure you have an adequate machine (at least quadcore CPU/ lot of RAM/SSD). If the choice is between spending programmer time trying to optimize compile times, versus spending a couple hundred dollars for an SSD, 99…

> The test was performed by compiling the source code below 128 times, calculating the average time.

Presumably, 127/128 runs have both the test file and the single header file in memory cache, so the distinction is moot.

Also, I find the conclusion that we should all just buy top end machines and ignore performance problems that don't manifest there fairly unconvincing. I think that kind of thinking is responsible for a good chunk of the reason the web is so bloated today. :-)

Re: C++ Headers are Expensive

#27

Post by CyberDildonics »

nanolith wrote: post #18
shereadsthenews wrote: post #16

Earlier quoted context omitted.

That only makes sense if you are planning to offer two implementations of your library. Which I of course urge you to not do. This article is about the STL headers. The reason std::sort beats the pants off all other languages’ sort routines is because the iterators of every collection, all specializations of swap, and the comparator can all be visible to the compiler. If they weren’t, it would be a lot slower. Premat…

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

Software still needs to be architected for performance from the start. Trying to micro optimize a loop before you know you need it what Knuth was saying to avoid.

Re: C++ Headers are Expensive

#28

Post by [deleted] »

RcouF1uZ4gsC wrote: post #15

> The test was done with the source code and includes on a regular hard drive, not an SSD. In my opinion, this makes any conclusion dubious. If you really care about compile times in C++, step 0 is to make sure you have an adequate machine (at least quadcore CPU/ lot of RAM/SSD). If the choice is between spending programmer time trying to optimize compile times, versus spending a couple hundred dollars for an SSD, 99…

[deleted]

Re: C++ Headers are Expensive

#29

Post by nanolith »

erubin wrote: post #25
nanolith wrote: post #18

Earlier quoted context omitted.

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is

If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)

Re: C++ Headers are Expensive

#30

Post by 21 »

loeg wrote: post #26
RcouF1uZ4gsC wrote: post #15

> The test was done with the source code and includes on a regular hard drive, not an SSD. In my opinion, this makes any conclusion dubious. If you really care about compile times in C++, step 0 is to make sure you have an adequate machine (at least quadcore CPU/ lot of RAM/SSD). If the choice is between spending programmer time trying to optimize compile times, versus spending a couple hundred dollars for an SSD, 99…

> The test was performed by compiling the source code below 128 times, calculating the average time. Presumably, 127/128 runs have both the test file and the single header file in memory cache, so the distinction is moot. Also, I find the conclusion that we should all just buy top end machines and ignore performance problems that don't manifest there fairly unconvincing. I think that kind of thinking is responsible f…

Doom/Quake were developed on a NeXT machine much faster and more capable than the targeted IBM PCs.

You don't need to develop on a $200 notebook to care about performance.

Post reply on HN