You might be right. My Pentium-compatible (Cyrix P166+) machine was the first computer that I owned built out of standard parts and most of the 386 and 486 systems I saw were from vendors who used custom motherboards and cases. The ATX spec wasn’t released until 1995, I don’t think I ever saw a 486 ATX case. My machine had an AT motherboard, so the AT to ATX switch was the thing that meant I had to buy a new case, but most of the I/O was on ISA or PCI boards.

Most earlier systems I’d used had on-board graphics (if you were lucky, it was EGA or CGA, but in a lot of systems it used some non-standard signal and connector and worked only with monitors from the same vendor), with graphics cards on expansion boards only ever an after-market add-on. IDE was pretty common by the 386 and ubiquitous for the 486, but older systems used a variety of disk interfaces. For a while the easiest way of expanding your disk was to buy an ISA ‘hard card’: a full-length ISA card with a disk controller and the disk physically mounted on it.

My P166+ had an S3 ViRGE PCI graphics card, on-board IDE, a cheap SoundBlaster clone (ISA). It came with an IDE disk and CD-ROM drive and EDO RAM. When I upgraded the CPU I needed a newer motherboard because the voltage changed and I couldn’t find the external voltage regulators that you could apparently buy for mine to get it working but I was able to replace the motherboard without changing anything else. I think I had three, possibly four, different motherboards in that machine. It ended up as a 350MHz K6-2, with the same case, disk (+ a second one), monitor, graphics card, and optical drive.

My next big upgrade was a 550MHz Pentium III. This time in an ATX case, which took the CD-ROM drive and disk from the old machine, along with a couple of the expansion cards (My VooDoo^2, for example). I upgraded this machine to an overclocked Athlon (1GHz, ran at 1.33 GHz). I had replaced the ISA sound card with a PCI one at some point along the way. I eventually replaced the PCI S3 ViRGE with an ATi All-In-Wonder 128 (which was about as fast for 3D as my VooDoo^2 and let my watch TV on my computer, which was important in a tiny student room). I later replaced it with a Radeon 8500.

Every upgrade from the 133MHz (pretending to be 166MHz) Cyrix 6x86 to the 1.33GHz Athlon was incremental. I didn’t buy a complete new computer at any point. At LAN parties, there was always a bit of trading as people who’d upgraded things passed on older parts to other people and we all did lots of small incremental upgrades. This may have happened with 486 and 386 machines, but I don’t think I ever saw it. I had a couple of salvaged 386 motherboards as a wall display and they were very bespoke things.

My next computer after that was a G4 PowerBook, so I stopped paying attention to PC hardware for a bit. I built a couple of NAS boxes since then and recently upgraded one (which I originally built 10 years ago) from a dual-core 1.6GHz AMD E-350 with 8 GiB of RAM to a quad-core Pentium Silver 5040J with 64 GiB of RAM, in the same case, with the same disks, so it looks as if motherboard upgrades are as easy as they were 20 years ago.

Here is a diff:

diff --git a/shutdown.go b/shutdown.go
index 2d02836..35d87c9 100644
--- a/shutdown.go
+++ b/shutdown.go
@@ -29,25 +29,20 @@ type ShutdownFunc func()
 
 // Internal method
 func (f ShutdownFunc) execute(c context.Context) {
-       done := false
+       done := make(chan struct{})
        // Execute ShutdownFunc in goroutine and set done = true
        go func() {
                f()
-               done = true
+               close(done)
        }()
-       for {
-               // Check if context canceled or ShutdownFunc finished
-               select {
-               case <-c.Done():
-                       // Context canceled, return
-                       return
-               default:
-                       if done {
-                               // ShutdownFunc finished, return
-                               return
-                       }
-                       // Otherwise continue
-               }
+       // Check if context canceled or ShutdownFunc finished
+       select {
+       case <-c.Done():
+               // Context canceled, return
+               return
+       case <- done:
+               // ShutdownFunc finished, return
+               return
        }
 }

The take away for me is that map as a generic type is lying to me. It is not like a generic Dictionary<K,V> in .NET where a value type is stored as part of the dictionary, at least I think it is stored that way. It is possible I don’t understand that data structure either! Instead, it seems the map always uses pointers as values. It simply fetches those values and dereferences them for me.

Looking at the profile in the original article, it’s plain that runtime.mapaccess2_faststr is about twice as fast as runtime.mapassign_faststr. So using an *int value seems to primarily avoid calling mapassign over mapaccess2 more than anything else.

Running both programs with perf shows that the program with map[string]int has a hotspot in runtime.mallocgc.

That’s what the original article indicates as well. I just don’t understand why that would be. That indicates mapassign allocates memory for every call, even when the key is found. But taking a cursory look at the source for mapassign_faststr, I don’t see any allocations in the existing key path. Do you still have stack traces for the runtime.mallocgc in the slower map assign version?

no, they aren’t.

It is a lie.