Hacker News Reader

Comment by thorax | Hacker News Reader

I can only imagine this is taking advantage of the fact that Windows task scheduling gives higher priority to threads which are currently receiving user interaction.

In certain cases, doing this would allow the process to handle returning data faster, especially if it was having to communicate with Excel a great deal and there was a lot of context-switching/waiting between the processes and you wanted to favor Excel's processing of the returned data over a background task with high CPU usage.

Perhaps the problem is that pieces of the Excel side were timing-out and causing all the returned data to be lost.

To read more about UI thread boosting in Windows, this article is a pretty good one: http://www.sriramkrishnan.com/blog/2006/08/tale-of-two-sched...

View on HN

I think your hunch is right http://blogs.msdn.com/oldnewthing/archive/2006/02/20/535440....

I think that's the opposite scenario. In what you linked, what happens is, you hold the mouse down on the window which prevents it from refreshing, which makes the actual task go faster (since its no longer trying to refresh the progress bar)

The actual task in Excel's case being running the query.

Our OS Prof. told us that some programs for Windows NT like compilers display progress bars to look more interactive (to the kernel, not the User) and to generate I/O completion events to get stuff done faster.

Gosh, I used to have a couple of games which would hang forever unless I wiggled the mouse a bunch at critical points, I wonder if that was the same principle? I had no idea task scheduler took interaction into account.

When we were developing a VB product at a previous company, we ended up throwing in the towel and calling the LockWindowUpdate function to improve our applications performance so that it was acceptable.

>LockWindowUpdate Function

The LockWindowUpdate function disables or enables drawing in the specified window. Only one window can be locked at a time.

http://msdn.microsoft.com/en-us/library/dd145034(VS.85).aspx

This isn't just a Microsoft thing. I've seen the same behaviour in OS X when running huge Applescript jobs. The entire script would excecute consistently faster if I sat there and wiggled the mouse around.

I've never really considered why that may be the case. This makes a lot of sense.

I find interesting, here we see the structure in RAM becoming almost as complex as the physical world (Or at least very dam complex.). This starts to make the heap react in way similiar to those in the physical world. We get a "mechanic" solution to a digital problem.

Reply on news.ycombinator.com