OSDev.org

How can I optimize a kernel?
Can you list what all you could to improve a kernel?

I have my list:
1]Using special keywords such as 'register' and 'inline' ,etc
2]Not making too many function calls and jumps


Have one more add it!

Coding smartly.

Serious, though. If you need a checklist, you need much more than just a checklist. Checklists don't cut it, because there are always exceptions to the rule. If you have the kind of userspace experience that is somewhat required for kernel work, you know how to write code efficiently...

What you are thinking of is generally called premature optimization. First step of optimization: implement everything, run it, profile it, find bottlenecks. Second step: try to improve algorithm used by the bottleneck (as opposed to "optimize algorithm's code"). Then, and only if it didn't worked, optimize it at source level.

There are some things that aren't premature, but should be second nature to good coders. MOst of them can be summarized as "avoid doing things unnecessarily". Unnecessary variables (e.g. those that are used but once), unnecessary copying (but be aware of things like compiler RVO), stuff like that.

@Solar: of course, but I wouldn't call "not making too many function calls" "avoiding unnecessary things"; if it becomes bottleneck, it can be optimized, but it's no use to pack as much code as possible in single function to "avoid making too many functions calls", because, in the end, it may be fastest part of the module being optimized.

Still not ready for OSdev you are.

First, learn about algorithmic complexity, you must.

Here's the list.

1) Use well designed algorithms.

- end of list -

Optimize hardware access (eg USB mass storage).

LindusSystem wrote:1]Using special keywords such as 'register' and 'inline' ,etc

Never abuse keywords, they can mess up compiler's optimization logic.

LindusSystem wrote:2]Not making too many function calls and jumps

Functions can be inline by optimizer, for complex software like a kernel, maintainability is way more important.

Got to agree with that last comment. Well-written, commented, legible code is far more important than worrying about ultimate optimization. If you really want a highly optimized kernel write it all in assembler (but you'll have a tougher time maintaining it). Unless you are dealing with a RTOS speed shouldn't, IMO, be your priority.

This doesn't detract from the fact that some functions are so frequently called that a small amount of optimization can have big effects. Good algorithms and judicious use of assembler are called for in such cases. But don't waste time optimizing a bootloader or initialization routine; it's only going to be called once.

Once you have your system up and running, and relatively bug free, you might want to look at it to see if there are any obvious bottlenecks. But, until then, I would even turn off compiler optimization which can make debugging a nightmare. Study the code produced by your compiler and be sure you understand exactly what various keywords are doing. The more generic you can keep it, the better as far as I am concerned.

Solar wrote:MOst of them can be summarized as "avoid doing things unnecessarily". Unnecessary variables (e.g. those that are used but once)

I assure you decent compilers are able to cope with variables used only once way better than people think they do. Not to mention that binding a subexpression to an identifier can improve readability.

It's not the compiler I am woried about, it's readability. Yes, a temporary variable can improve readability, if the subexpression is so complex that taking it out of the main equation outweights the introduction of another identifier, and if the scope of that one-shot identifier is kept small (i.e., something between "the line directly in front of the actual use" and "the same screenful of source", maximum).

But frequently, I see one of these:

• Variable bound to subexpression in one place, with the only use being somewhere else entirely (if C/C++, subexpression in the header, use in the implementation file).
• Variable bound to subexpression to "explain" the subexpression through the name of the variable. (Comments, anyone?)
• Variable bound to subexpression without meaningful variable name or comment.
• Local variable bound to passed-by-value function parameter, with the function parameter not being used for anything else.

My favourite so far was:
Real-life production code. I quote: "Do you know how expensive a function call is?"

"Do you know how expensive a function call is?"

Perhaps 3ns on a modern desktop.

typically ten times the nominal value if you're rdos

Design your program such that there is minimal duplication of functionality. Then, when you optimize one algorithm, the maximal amount of code is affected. Also, depend on the properties of specifics algorithms as little as possible. Then you can optimize those algorithms more aggressively without breaking existing code. These of course are good general rules for writing code.