Benchmark them - original and your revised. (Their equivalents, that is,
in userspace with rdtscll() )
Put them into a test-harness calling them million times (or some such).
Look also what assembly the compiler produced, e.g. that it didn't optimize
away error paths.
> Yes, it's more code, so the kernel is a little bigger, but it should be
> faster at the same time, and memory should be less of an issue nowadays.
That is common fallacy. Learn to code in environments where you
have to account for every byte of code and ram usage, and your code
will be fast even in bigger systems.
> Here's the patch if you want to apply it (i have only compile tested it,
> I haven't booted with it).. This patch applied to the 2.5.56 kernel.
....
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/