Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work.
A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this:
What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)
I bought a new HP Stream recently and it's been delightful to run Lubuntu on - everything worked out of the box. Even two finger scrolling in Firefox with the trackpad.
I have other machines that I use for my day job, but it's such a fun little computer to use.
I work on an app that edits and renders fairly complex indoor floorplans to SVG, all using React.
We deal with large hospitals and airports, so it's normal for us to have tens of thousands of components mounted at once - pagination isn't a viable solution for our purposes.
We've had to tap basically every optimization that React apps can do when managing large numbers of elements - however this has been worth it for us:
- We can use the same code to render interactive plans on the client, and to render to print-quality PDFs on the server
- We can use the same framework in our UI and plan rendering
The downside is that it's more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making.
I couldn't resist trying this and making some more detailed instructions for getting better images out of iOS. Turns out that you can get fairly good results without any fancy software.
Front-row seats and exit row seats are paid upgrades because of the extra space. They aren't paying economy - they're paying slightly more.