Slash Boxes

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
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: 1) by morpheus on Sunday March 16 2014, @10:31PM

    by morpheus (1989) on Sunday March 16 2014, @10:31PM (#17308)

    Well, we are predictably hearing a chorus of professionals crying out: do not do it. This does not answer his question though. How about these simple steps:

    1) Think of the standard libriry/outside code as prototypig tools, put together a good test case.

    2) Try to identify and measure a small task that in your opinion slows you down.

    3) Educate yourself on how to improve this one task and make it run faster than what you have

    You have to have an absolutely clear mind about 2) and 3). The truth is, a lot of `standard code' is suboptimal but good enough (for once, `use qsort() for sorting' is bad advice, sometimes even bubble sort is a lot more appropriate). If you are truly dissatisfied with speed, look at the algorithm first. C is a fantastic language but it does have limitations simply because it is based on a specific model of memory and computation (all those malloc's and register qualifiers have a specific class of computer architectures in mind). Sometimes writing in assembly makes the code easier to write and understand(I did not say more portable). Check this example out:
    If you are convinced it is C you want get a deep understanding what happens when a function is called, a pointer is dereferenced, etc. Optimization is not magic, either, just a lot of linear algebra. Once you have looked at all this you will come around ... to what everybody else was saying: learn more but do not reinvent the wheel ... unless you really want to.