Why did moving the mouse cursor cause Windows 95 to run more quickly? • Hacker News Board

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#181

Post by dbtx » Thu, Jul 04, 2019, 5:04 AM UTC

dbtx wrote: post #145

I have a terrifically annoying bug that shows up somewhere between X and GTK and all Gecko-based browsers. While I'm scrolling down in a web page with the mouse wheel, within a few seconds the page will stop moving. The mouse will still move around, but it will stop changing its cursor based on hovered elements, and further mouse actions will do nothing. It will unjam itself something like 30 seconds later if I wait,…

> ${somehow}, ${something}

Sorry, something resurfaced-- I think I remember now that I switched on seconds for the sake of finding out more precisely how long a jam would last. Immediately it became obvious that they didn't last long anymore, and that the reason it used to be "30-ish seconds" was whenever the minutes finally changed, it broke loose just the same way.

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#182

Post by Stratoscope » Thu, Jul 04, 2019, 5:08 AM UTC

layoutIfNeeded wrote: post #115

Stratoscope wrote: post #99

Earlier quoted context omitted.

Or, since GP said "mark all text", use Ctrl/Command+A. Of course neither of these would demonstrate the effect they were talking about.

ggVG

  ggVG

I typed that into Notepad and it did exactly what I expected: it displayed 'ggVG' in the edit window. I can even save it to a file!

Thank you for the tip.

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#183

Post by mikorym » Thu, Jul 04, 2019, 5:16 AM UTC

And when you click in Excel while it is stuck computing, does it prioritise the cell you are clicking on, or could it be that it actually does compute more quickly then?

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#184

Post by StillBored » Thu, Jul 04, 2019, 5:22 AM UTC

Given all the me too's. How about this one, same basic problem in the mid 2000's with linux. We were running a few servers with a normal desktop distro. I got the bright idea that since no one was actually on the console we could save some ram/CPU by changing the default runlevel and not starting X/etc. Took about 2 days before someone complained we were running about 20% slower than normal.

I think in the end the solution was to just fire off a X/xdm pair as I wasted a few days looking at scheduling/numa/shared interrupts/etc trying to get a good solid solution that didn't require starting X. We ran it like that for a couple years until eventually someone tried it again (after a bunch of software/hardware upgrades) and the perf didn't fall off.

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#185

Post by NeedMoreTea » Thu, Jul 04, 2019, 5:34 AM UTC

Nition wrote: post #175

delinka wrote: post #129

Earlier quoted context omitted.

Absurd initial estimate? All of the estimates tend to be absurd. Done in 30s ... I mean 15min ... ah, 10s ... 1hr 7min ... Oh, come _on_ ...

Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png

Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.

It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#186

Post by bcaa7f3a8bbc » Thu, Jul 04, 2019, 6:38 AM UTC

NeedMoreTea wrote: post #185

Nition wrote: post #175

Earlier quoted context omitted.

Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png

Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged. It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.

How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:

1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.

2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.

Are there any other points worth noting?

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#187

Post by Yizahi » Thu, Jul 04, 2019, 7:44 AM UTC

While we are at it, can anyone tell me why selecting large text in a scrollable window works faster when you move the mouse?

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#188

Post by unionpivo » Thu, Jul 04, 2019, 8:53 AM UTC

mr_toad wrote: post #165

samstave wrote: post #36

Earlier quoted context omitted.

Get off my lawn! But what newbies will bever know the heck of: dip switch settings for IRQ for modems. Thats what literally got me into computers... In order to dial up BBSs and play tthe Pit and dl warez. —- Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - m…

> But what newbies will bever know the heck of: dip switch settings for IRQ for modems. And dip switches to set hard drives to primary/secondary. Get that wrong and your machine didn’t boot.

those were jumpers :)

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#189

Post by isostatic » Thu, Jul 04, 2019, 9:01 AM UTC

UI_at_80x24 wrote: post #13

This wasn't just restricted to COM port based I/O either. Back then I had a Logitech bus mouse. The mouse was connected directly to an ISA card, and didn't use the COM ports as most mice did back then. (I needed the extra COM port/IRQ for my modems.) I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled fo…

> That way when I would walk-away from an install

But a few minutes later you'd be back to swap in floppy number 18

Re: Why did moving the mouse cursor cause Windows 95 to run more quickly?

#190

Post by NeedMoreTea » Thu, Jul 04, 2019, 9:03 AM UTC

bcaa7f3a8bbc wrote: post #186

NeedMoreTea wrote: post #185

Earlier quoted context omitted.

Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged. It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.

How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that: 1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time. 2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windo…

Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.

The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.