Communication vs. documentation

[ZombieFan]

Okay. I think we just have to agree to disagree here. I'm coming from a development team who values developer's time over code performance. You're coming from somewhere which values code performance over developer's time.

If you do have some reading time and want to understand more about my point of view then do have a search for "clean code".

Cheers

 

[D.P.]

Okay. I think we just have to agree to disagree here. I'm coming from a development team who values developer's time over code performance. You're coming from somewhere which values code performance over developer's time.

If you do have some reading time and want to understand more about my point of view then do have a search for "clean code".

Cheers

I don't disagree with what you are saying, clean code and suitable factoring is fundamental to maintainable extensible code, and premature optimization is the root of all evil. However, if you ever code in an environment where performance matters then there are small trade-offs to be made. Factoring out a very simple single line operator used inside an inner loop may not be beneficial for readability vs performance trade-offs.

Our work involved processing many gigs of data, applying fairly sophisticated machine learning, data mining and statistical algorithms and making a data stream available n real time with minimal latency. We already have enough latency issues due to network delays and overhead which leaves us with a certain amount of time to process data. If we can't process data in this time then the value of our product goes down.

We also prefer not to simply throw extra CPU resources to try to reduce costs as this doesn't scale well, especially for code paths that cannot be parrellalised. As the data load increases performance improvements can add up to significant gains that far outweigh the increased development time.

 

[Lightnix]

Compilers might inline a function. They might not, even if you try to force them to inline wiht the inline keyword they are free to ignore you. You have no control, and the reasoning for not inlining is not well documented.

I love the struggle between MSVC++'s desire to let the programmer specify inlining manually and its desire to optimise in a way that produces sane code as illustrated by its three different supported inline keywords: inline, __inline and __forceinline (where apparently even the latter doesn't work 100% of the time).

 

[D.P.]

I love the struggle between MSVC++'s desire to let the programmer specify inlining manually and its desire to optimise in a way that produces sane code as illustrated by its three different supported inline keywords: inline, __inline and __forceinline (where apparently even the latter doesn't work 100% of the time).

Yeah, I really don't get why manually specifying a function to be inline basically gives an undefined behavior, you don't know if the function is inlined or not. I can never work out what the compiler is doing.

I would really prefer if the compiler always inlined when you specified this, even if it damages performance. Its the same for GCC and CLANG so I assume there is some underlying reasons but you never know. Compilers are mostly pretty stupid compared to developers.