Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Sunday March 16 2014, @03:28AM   Printer-friendly
from the premature-optimization-is-the-root-of-all-evil dept.

Subsentient writes:

"I've been writing C for quite some time, but I never followed good conventions I'm afraid, and I never payed much attention to the optimization tricks of the higher C programmers. Sure, I use const when I can, I use the pointer methods for manual string copying, I even use register for all the good that does with modern compilers, but now, I'm trying to write a C-string handling library for personal use, but I need speed, and I really don't want to use inline ASM. So, I am wondering, what would other Soylenters do to write efficient, pure, standards-compliant C?"

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Sunday March 16 2014, @04:39AM

    by Anonymous Coward on Sunday March 16 2014, @04:39AM (#17079)

    Don't be afraid of memcpy. The compiler can optimize it well. If you insist, you can even pick the optimization strategy from the command line.

    Use the "restrict" keyword. It's available as __restrict on most ANSI C compilers, including Visual Studio and the default setting for gcc. Put gcc in C99 mode with -std=gnu99 if you want it without the underscores, or just #define it.

  • (Score: 2) by forsythe on Sunday March 16 2014, @05:42AM

    by forsythe (831) on Sunday March 16 2014, @05:42AM (#17099)

    To be pedantic, using gnu99 might run against the goal of being standards-compliant. Using -std=c99 would probably be better for the submitter's purpose.

  • (Score: 3, Insightful) by cmbrandenburg on Sunday March 16 2014, @01:52PM

    by cmbrandenburg (3744) on Sunday March 16 2014, @01:52PM (#17174)

    No, do be afraid of memcpy, as well as malloc. These are two of the four horsemen of poor performance [pl.atyp.us].

    After you've picked the best algorithm for your needs, one of the next best optimizations you can do is to avoid unnecessary memory allocation and copying. The key is developing a good eye for "unnecessary." For example, a common anti-pattern in intra-process communication is passing messages by copying one buffer to another. There's usually a better way, one that involves passing a pointer to the message rather than all of its content.

    What makes extraneous memory allocation and copying insidious is that no single memory allocation or copy will ruin your program. However, when they're repeated throughout a large code base, the inefficiency adds up--all while becoming a diffuse inefficiency that poses no single bottleneck. That is, once you realize that memory allocation and copying are a problem, it's too late to be an easy fix.