6 ms·
This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did
by peckrob 10y ago
This reminds me of one of my favorite old tech stories.
A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner in it when you ran it with verbose options.
At the time I was on a slow dialup connection as I was on break from school, and something weird would happen. Every time I ran the script to test it, my Internet connection would become nearly unusable. But as soon as the script finished, it would suddenly start working again.
As you can imagine, this was very confusing since the script was running entirely on a remote system. What the hell is going on?
This stumped me for an hour or so until I ran it without the verbose option ... and it didn't happen. Then I finally realized what was happening: I was refreshing the spinner on EACH ROW and remote machine was going through the rows so quickly that sending refreshes for the spinner saturated my tiny dial-up connection. Changing this to only update once a second fixed it entirely.
And that's how I DoS'd myself with a spinner.
- kelvin0 10y agoNice foot gun story. If you had a T1 at the time, you would never had noticed such a pitfall.
- peckrob 10y agoPretty much, yeah. I never noticed it on campus because I was sitting on a 10 megabit connection. That added an extra dimension to the confusion because I was sure this never happened when I was on campus, only when I was sitting 300 miles away. It was still happening if I had bothered to look at the network stats, just not enough to entirely saturate the connection.
- agumonkey 10y agoI often advise to write code on "obsolete" tech. It makes every bit of cruft obvious.
- kuschku 10y agoI test all of my apps on an old Moto G, second generation, on throttled mobile internet (64kbps). That’s the average worst case user. This also means I notice massively if an app has hardcoded timeouts, or loads massive amounts of data.
- flukus 10y agoI've got a similar one. I was working on an app once where the current results were being logged to a text box, nothing too fancy, but I noticed it got a lot slower on larger blocks. Changing "textBox.Text = textBox.Text + newline" to "textBox.Append(newLine)" cut >99% of the CPU time. On the same project I discovered that "System.Envireonment.NewLine" was a relatively expensive call on c#, caching the result of that property was another 50% cut to CPU.
- androbabu 10y agoYour story reminds me a current scenario @peckrob .. For Android Application development, we used to connect devices to computer via usb and would see the device's log in logcat tool (Android Studio). The device, in general, spawns lots of logcat messages during a debugging session and would eats up CPU. The case is still worse that the tool stucks when device is connected over wifi (wifi-adb) as the data transfer is little lower in wifi than usb.