3.7X speedup from removing a call to sleep
trac.webkit.org
trac.webkit.org
The original author of this comment (not me, I just imported the code) believed that it improved performance on a given server-side workload.
The person who removed the sleep, Geoff Garen (a colleague and a friend), is a good programmer. I am confident that he read the comment before deleting it. However, his actual performance measurement trumps the comment.
BTW, here is Geoff's snarky response on reading the posts here that mention the comment above the sleep() call: <http://www.quickmeme.com/meme/3qqgwz/>. I agree with him.
Client gives me a Help Desk Ticket. User claims batch job use to run in 5 minutes but now runs for hours. The logs confirm this. The commit logs show that an offshore programmer forgot to remove a 10 second sleep command from inside an iteration (for debugging I presume) before promoting to production. I removed it and got a 100X improvement in throughput.
My client said that now his user loves him; what did I do to fix it so fast?
When I told him that I removed the Sleep, he said, "No! No! No! Change it to a 5 second Sleep so I have something to give him the next time he complains!"
Unnecessarily mentioning a characteristic of an individual is a sign of selfish, biased, and/or malicious thinking. Do you mention "American programmer" whenever recounting their bugs? It appears you have an agenda of promoting negative stereotypes, presumably in your favor. This is lame. In the future, you'll appear more credible if you omit this bigotry from your comments.
I am certain there are thousands of programmers, male, female, gay, straight, onshore and offshore who are much better than you (or me.)
My guess is that he was having a jab at the offshoring mentality.
I suspect the presumption that off-shore means lower quality comes from past experience working with an off-shore team selected based on their perceived lower cost. I've found that when you set the bar high for off-shore hires, regardless of cost, you end up with high-quality people.
You can't solve prejudice and bias by pretending that people's race, gender, nationality, height, weight, shoe size, etc. don't exist. They do, they always will, get over it.
In my experience, programmers who emphasize that "offshore" programmers are bad seem insecure about their own skills and job stability. The same is true of sexist men who go out of their way to mention when a mistake was made by a woman but never explicitly highlight when it was a man.
"offshore" is synonymous with "cheap(er) labor" in the US programming world, and is an accurate statement since that's what it's generally used for ("let's send it to XXX and it will cost us 1/10 as much")...
How many times do you think outsourcing happens in the US because they are looking for higher-quality code? 1%, 10%, 50%, 90% of the time?
"cheap(er) labor" is also synonymous with a bad product/service, because you often get what you pay for.
Are there exceptions to all this? Yes. Sometimes you can't find good quality coders in the US, but I doubt this is why outsourcing happens most of the time.
He might have generalized by adding that detail ("offshore") but that's not biggotry IMO as much as it is a flavoring.
I think it's been established that when you outsource for cost, you get back a product that cost you more in the long run.
Again, there are exceptions to this, but that's not what we are talking about.
-- Damon RunyonHaving worked extensively with outsourced code (4+ years) I can tell you without a doubt the vast majority is poor quality crap, more so than "insourced code" by far. But... Everyone produces bad, buggy code at times.
The problem is that the person who evaluates quality has no real understanding of what is being evaluated. This leads to price being the deciding factor. Most of the code I've seen coming from price-driven software factories is awful.
In fact, the same problem has plagued the IT industry since forever. Almost no company successfully competes on quality, because the customer chooses the cheapest offer in the majority of cases.
And here is the crux: define the quality of a delivered software project and put a number on how much higher quality would have saved the customer. Nigh impossible.
The only solution seems to be going into a specialty niche where high quality is required, so any incumbent competitor will fail, unless they deserve to win, because they deliver your level of quality.
I have yet to experience that joy.
Rather, offshore means lots of unnecessary documentation, train someone to do my job (promoting me to "lead"), watch them get it wrong, try to coach them onto the correct path, high turnover (so I have to train and coach again in a few months), do a complete rewrite at the 11th hour, then be blamed by the bean counters that I sabotaged the effort somehow.
No doubt the same thing happens in house. But with in house, if we find a good egg, we get to keep them, get some ROI back from the learning curve.
I see you've never worked with offshore development.
If this is true, then we're all in deep sh*t, as we'll all be working for Chinese-level wages soon.
When interpreting the story, isn't it important that readers understand that the programmer who added the call to sleep was far removed from both the help desk and the end user of the software and was also unreachable at the time the call was discovered and thus that the author, who worked at the help desk, had to presume that the call was left in the code mistakenly? It's only later in the story that readers (and the author) learn about the ticket-submitter's unusual preferences for satisfying the end user. And it's only then that another possibility dawns upon readers: that, perhaps, the "offshore programmer" knew more about making the stakeholders look good than initially given credit for.
If the author of the parent post is not allowed to reveal that the programmer was working "offshore," how does the story get told at all?
Offshore could imply a number of things. Let's be nice at first and pretend that this means "across the Bay," or maybe on Alcatraz.
My best guess: The offshore person does not have the development culture present in the "mother ship". Best practices are often stuff that you learn in the hallway, from casual conversation, or watching over someone's shoulder. Attachment to the product's quality is probably lessened, too -- distance does this, even in the days of ten-millisecond-scale pings to the other side of the planet -- and it's easier to "go to lunch" on a problem and worry about it later when a floor-full of engineers aren't actively crowding your cubical about a lame checkin.
Hell, I have enough problems getting two /adjacent buildings/ to talk to each other.
Now, add a time-zone difference that further impedes communication. Add siestas, and mismatching holidays, and language barriers. There are more.
Even before we add in a different country's culture, we have severe issues with the average offshore developer's perception of what's important and how to work effectively.
I'm not going to say "Indian / Pakistani / Kiwi programmers can't code their way out of a paper bag", but when you add the stereotypical stuff to all of this (bad management, poor hiring practices, general slap-it-together attitude), it's /bad/, and not unwarranted to mention, even in passing.
That said, our sleep locks are actually adaptive locks, so on SMP systems they'll spin for a bit before giving up and asking to be descheduled.
Spinlocks in linux are the "last resource locks", usually in kernel code only in situations where you can't have the scheduler kicking in but can have a race condition (in SMP systems usually)
So it's basically interrupt handlers.
Will 1) really happen often enough to not use simple spin locks?
If you have:
… a multithreaded process with shared resources that need locks
… and for the uncontested case your spinlock is much faster than your next fastest lock
… and you have resources for which the probability of a contested access is very close to zero
… and the locks are only held briefly (relative to compute quantum) (especially if they are held shorter than thread context switch)
You may find that the speed gained by using the spinlock is a win even if once in a while you end up burning your compute quantum because a thread got suspended holding a spinlock.
You need to be careful though.
But what sort of effect will this have on page rendering? Anyone in the know care to comment on the specifics?
edit: improvements to my shoddy wording.
Possibly not desktop performance at all since I believe GC is done in a separate thread and (from my understanding) you never wait on it, unless you are really memory constrained.
Could make a difference on IOS where I believe you actually don't have this GC memory scavenger thread.
Anyway, the source is quite readable and everyone working with WebKit on one level or another could benefit from taking a look. At the very least it gives you a feeling for the tremendous effort from a huge number of people that the WebKit project really is.
I would guess this is relevant only for GC in Safari, since it uses the WebKit JS engine, and not Chrome (which uses a completely different JS engine, V8).
It's also likely only a speedup in a specific GC benchmark. If it had helped in say the SunSpider benchmark, I'm pretty sure it would have been fixed a long long time ago.
Spinlock implementations sometimes use sleep() calls in them to yield the current thread to others that may be ready to run but are currently being blocked. It's still a bad code smell though because spinlocks, at least in user space code, are used to avoid the overhead of yielding to other threads. There are also other locking mechanisms, like mutexes/futexes, that will accomplish the same yielding behavior if it's really needed, like if it's anticipated that the code waiting for the lock may be held up for a while.
The real fix would be to make context switches faster, this is just a data-driven tweak rather than a general solution.
He eventually replaced a particularly ugly and complicated system with a much simpler system, and thus he met his goal of going into the negative. Less code is better code.