Frank writes “Performance breakthroughs seem to come in two varieties: easy and hard. That’s no platitude; the boundary between the two is surprisingly clear. Although in some cases it has taken considerable genius to realize their first application, they’re easy to understand. The other kind involve careful measurement, specific knowledge, and a fair amount of tuning. Good programmers can operate in either the “hard” or “easy” mode. This article offers a paired collection of 4 hard and easy tales from real (programming) life.“
Improving Linux Performance
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
Interesting article, gives some insight into how to make your program “seem” faster, which is a topic they don’t talk much about in the classroom.
The sorting stuff was somewhat vanilla, though. I think it would have been better if he had focused on end user perception of speed completely.
-Erwos
I read his first example about giving “feedback” on long computation and it is so simplistic it is worthless.
Guessing the time something will take can be very hard.
Having a way to report the length estimated by the lower process to the UI can be fairly complex because many layers can be involve.
How about showing us how to apply all of those patches to a kernel to speed it up?
Um, sorry to basically to tell you to rtfm, but…
man patch
It all depends and yes you should read the patch man page.
However, you do to the top of source tree and put *.patch files there.
The all depends part comes in here. If the patches are fairly standard then it is just a patch -p0<name_of_patch.patch.
Do one after the other until all have been applied.
If it fails not being able to find the file there are two options.
1. The patch was designed with a different offset (don’t even ask) and you have to do a patch -p1<name_of_patch.patch.
2. The patches were designed to be applied in the exact subdir where the source code files it wants to patch are. So copy the troubled patch into that subdir and then do the patch -p0<name_of_patch.patch.
I have only applied patch files to the source code of different projects never kernel patches myself.
So, there may be different options or common conventions when applying kernel patches that I am not aware of.
Therefore, do not blast my above post all knowing kernel hackers just politely correct me and move on.
That was one of the less worthy articles. Talk about thin on content…
that is about it. p0 or p1 then ofcource the configure and compile stages. other than that your golden.
it is so coolthe first time you do it. you realy get the sence that you are in control of your system especialy if it adds a feature that you need (ACPI in my case)
“Improving Linux Performance” again?
<facetious>Must be because they’re using all those Linux-specific tools like ksh, tcl, and Python…</facetious>
And here I thought IBM would be delving into what kernel modifications they made to Linux to make it suitable for big iron hardware…