Opened 16 years ago
Closed 6 years ago
#30 closed enhancement (wontfix)
Investigate possibility of using unlikely(), likely()
Reported by: | Martin Decky | Owned by: | Martin Decky |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | helenos/kernel/generic | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
Use the constructs unused(), unlikely() and likely() in relevant parts of the code.
Change History (8)
comment:1 by , 15 years ago
Component: | → unspecified |
---|
comment:2 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I am closing this ticket as it does not really describe an improvement. If you are concerned with the performance of the kernel, then I suggest you log a ticket for that. Analyzing/profiling the hot paths and finding a way to improve performance (noticeably) is a good ticket assignment. Suggesting to obfuscate the code for no provable benefit is not.
comment:3 by , 15 years ago
Component: | unspecified → kernel/generic |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
Summary: | Use unused(), unlikely(), likely() → Investigate possibility of using unlikely(), likely() |
Type: | enhancement → task |
OK, maybe I don't have to close this ticket, but let me rephrase this. We are talking about hand-optimization. Hand-optimization should always be used as a last resort — avoid them as much as possible. What we can do:
- Profile the kernel and determine the hottest functions/paths
- Identify if() statements on these hottest paths
- Try placing likely()/unlikely() in appropriate places and measure the performance benefit.
- For individual uses of likely()/unlikely() which bring considerable performance improvement, consider integrating them.
- Any use of likely()/unlikely() that cannot be supported by both logical explanation and measurement should be avoided.
Another note: What is the unused() macro? If it is meant to be some way of annotating unused variables, it might be a good idea, but completely unrelated. Please open a separate ticket for discussion thereof.
comment:4 by , 14 years ago
Type: | task → enhancement |
---|
comment:5 by , 13 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:6 by , 10 years ago
Milestone: | 0.5.1 → 0.5.2 |
---|
comment:7 by , 8 years ago
Milestone: | 0.6.1 |
---|
comment:8 by , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
The need for this has been very low in the last 10 years. Closing now.
I am strongly against this. You are basically trying to hand-optimize the code for speed. If you can actually attain some noticeable speed improvement by putting this in a few extremely hot spots, then maybe. Otherwise you are just obfuscating the code. Moreover, in many times your guess about what's 'likely' can be utterly wrong.