Sometimes I miss being able to hear the hard disk read heads moving around. It was a surprisingly accurate way to tell what your computer was up to. Someone must have made a simulation of this, right?
Jim asked about our "20 queries," his incisive way of learning about an application, as a deceptively simple way to jump-start a dialogue between him (a database expert) and me (an astronomer or any scientist). Jim said, "Give me your 20 most important questions you would like to ask of your data system and I will design the system for you. " It was amazing to watch how well this simple heuristic approach, combined with Jim's imagination, worked to produce quick results.
Jim then came to Baltimore to look over our computer room and within 30 seconds declared, with a grin, we had the wrong database layout. My colleagues and I were stunned. Jim explained later that he listened to the sounds the machines were making as they operated; the disks rattled too much, telling him there was too much random disk access. We began mapping SDSS database hardware requirements, projecting that in order to achieve acceptable performance with a 1TB data set we would need a GB/sec sequential read speed from the disks, translating to about 20 servers at the time. Jim was a firm believer in using "bricks," or the cheapest, simplest building blocks money could buy. We started experimenting with low-level disk IO on our inexpensive Dell servers, and our disks were soon much quieter and performing more efficiently.
[1] https://cacm.acm.org/magazines/2008/11/549-jim-gray-astronom...
As an aside I get the feeling software is being written more and more to assume SSDs. Starting up visual studio from fresh on my machine will thrash the disk. Disk read is roughly (average) 2MB/sec throughout. Disk queue length will hit 10 several times. It takes 4 mins 50 secs (290 seconds) before the disk will calm down - I just timed it. Total mem for the process when all's finished - 204MB! That's all!
My feeling is the VS code is spawning many threads which are each fighting each other for the disk. It's really, really poor.
For my family members that have laptops with those shitty 5400rpm HDDs with 8MB read/write buffers - I can't blame them and just tell them to upgrade to an SSD. I've witnessed Windows update hogging 100% of the disk activity for 30+ minutes after reboot on these machines until they're actually usable...
But for my developer friends who I figure should know better, they never seem to think of looking into disk activity. It's almost always things like applications hanging/blocking on disk due to lots of different processes trying to read/write at the same time on an HDD or "small" RAM size causing constant thrashing on a disk due to memory being paged in and out of swap constantly.
I agree with this observation in general. I don't use VS Code in particular but you've given solid evidence of a seek-heavy/HDD-unfriendly workload.
> My feeling is the VS code is spawning many threads which are each fighting each other for the disk. It's really, really poor.
I agree this is a poor match to your hardware, but if you're saying this is evidence of poor engineering, I disagree. IDEs' most demanding customers are using high-core-count CPUs with SSDs and expect top performance with heavy workloads. So the Visual Studio team needs to make this fast, and I don't think they have much reason to care about HDD-based installations' performance. Most software developers won't have trouble affording SSDs to store their OS files and current project, and the ones that will aren't paying to drive IDE development either.
Honestly, I'd strongly recommend you get an SSD - prices are really cheap nowadays.
It can do refactoring etc. and has context-sensitive help/completions but honestly I work in emacs because it offers so much more - except the high-level refactoring etc. Omnisharp works, sort of... VS just isn't as good as emacs in many, many basic ways.
Anyway, I'll look at SSDs and stop nattering about editors.
In fact, after working with VS for years and getting more and more annoyed by the lag, I tried JetBrains Rider - I'm a total convert, it's one of my favourite ever pieces of software! The UI takes a bit of getting used to if you've been using VS for a long time, but not that much. Plus there's an excellent dark theme that is quite close to VS's.
Rider is absolutely stuffed with features and config switches - it's close to feature parity with VS, with VS able to do a few things Rider can't, and vice-versa. Rider absolutely flies by comparison to VS, and is more stable too. Oh, and edit-and-continue "just works" in Rider, whereas I've always found it problematic in VS.
After getting an SSD, trying Rider is my next suggestion :)
The thing about "I do think [VS] a great IDE" is you haven't experienced emacs so you don't know what can be. What emacs is bad at: all the things VS is good at, the high-level code 'understanding'. But honestly for writing/modifying/moving around/various other stuff, emacs is just so astonishingly comfortable when you get used to it. It's not "I don't need to use the mouse", more "I barely need to think about it". And then you've got stackable clipboard, registers, macros from heaven, regexps that just work, so much more...
And perhaps best of all, it's written by programmers for programmers. VS feels like management have been involved in featuritis and "UI/UX experts" as they think of themselves but aren't, have been allowed out of their cage too often.
I'll not recommend you try emacs, it's a lot of investment but if you could get emacs to do high-level stuff as well as the low-level... Right, time for me to stop hijacking this thread!
Likewise being able to hear if you and the BBS were properly connecting or not. Hearing your modem retry the handshake after dialling 90 times to get into a popular one was heartbreaking.
Later I've found out that piece of code was written by Wozniak himself.
Demonstration: https://www.youtube.com/watch?v=gWJtGZOp3K0
> We created a network monitoring system, Peep, that replaces visual monitoring with a sonic `ecology' of natural sounds, where each kind of sound represents a specific kind of network event.
https://www.usenix.org/legacy/publications/library/proceedin...
I've tried a bunch of the popular linux disk/resource usage monitors but I find none are as flexible/nice to look at as Windows' Task Manager overview graphs and Resource Monitor. Any time I'm using a Windows system I will dedicate a monitor to just having Resource Monitor's disk usage tab open (although it can result in nontrivial CPU usage under certain disk access patterns).