Hacker News Reader

Comment by illiarian | Hacker News Reader

Yup. A lot of modern software is beyond parody now: https://twitter.com/cmuratori/status/1640827575437250561?s=2... (the "new and improved" Microsoft Teams takes 9 seconds to display under a kilobyte of text, including 3 seconds to just display a splash screen)

View on HN

Ironic that all the devs being asked Leetcode algorithm optimization questions during their interviews don’t seem to be putting any of that to use where it actually matters!

I’m sure the Teams splash screen is O(1).

Algorithmic optimization is more than just about asymptotic complexity; reducing that leading coefficient is equally important. Constant time is meaningless if the constant is measured in seconds.

That was the joke. Leetcode usually only cares about asymptotic complexity.

I thought leetcode cares about the actual run time.

It measures runtime, but not reliably, multiple runs of the same code can report very different runtimes. My impression is the focus is mostly on getting the time complexity right.

Suggestion (not for you specifically, just a general comment): never answer leetcode questions right away. Push back and ask the interviewer to describe the problem they're actually trying to solve. Probe their constraints - memory limitations, throughput. 99% of software isn't going to be the leetcode algorithm but the reasons for it being there. (Caveat: I haven't had to be in an leetcode driven interview for some years, and this probably doesn't work great with people that love algorithms more than getting something done.)

I recently took a computer vision course taught in both Python and C++, students chose the language they used for assignments. I signed up twice and did both languages. The C++ versions of the exact same tasks are not only significantly faster, they also occupy exponentially less memory, and in a few tasks I was able to trivially introduce C++ threads for jaw dropping speed improvements, while Python's situation for such optimizations is dismally convoluted. From the experience of this class taken twice, it really looks like there are serious gains to be had with an optimization pass via C++/rust/go for many systems that could benefit from multi-core implementations.

The ffmpeg patches of a few lines of assembly that make 10-100 fold improvements on slow C amaze me

I worked on an facial recognition system written in C++ that used SIMD optimizations to achieve 25M facial compares per core per second. On that same system I wrote an optimized ffmpeg player library that only consumed one core while doing a few hundred frames per second with 4K video.

Python is a glue language. It is one thing to use it to string together bunch of algorithms written in C. But somebody's got this genius idea of using it as a general language and now we have this backend frameworks that are 2 orders of magnitude slower than they should be.

Not just the speed, but the memory use.

A popular approach for Python web serving is to launch a number of "workers" (eg via gunicorn, etc), that hang around waiting to serve requests.

Each one of these workers in recently running code (here) idled using ~250MB of non-shared memory. With about 40 workers needed to handle some fairly basic load. :(

Rewrote the code in Go. No need for workers (just using goroutines), and the whole thing idles using about 20MB of memory, completely replacing all those Python workers. o_O

This doesn't seem to be all that unusual for Python either.

In a forking model that shouldn’t be the case, I guess all the workers are loading and initializing things post-fork that likely could have been accomplished pre-fork?

That said, Python devs are some of the worst engineers I encounter, so it’s not surprising things are being implemented incorrectly.

Last I heard, forking wasn’t a very effective memory-sharing technique on CPython because of the way it does reference counting: if you load things in before you fork, when the children start doing work they update the refcounts on all those pre-loaded objects and scribble all over that memory, forcing most of the pages to be copied anyway.

There seems to have been some recent-ish work on improving this, though: https://peps.python.org/pep-0683/#avoiding-copy-on-write

Next time someone tells me that there is no problem with the bloated state of modern software, I'm going to point them to this video where a multimillion dollar development team congratulate themselves on reaching Windows 3.1-tier performance.

You may enjoy this article about writing a Slack client for Windows 3.1:

https://news.ycombinator.com/item?id=21831951

AFAIK part of the Teams API has been RE'd and is sufficient for writing an IM-only client, so it would certainly be an interesting exercise to do the same as above but for Teams.

As demonstrated (heh) by the demoscene, the TI calculator scene, game development, etc, restriction breeds innovation.

Yes but developer experience !!

Don’t worry; Teams 2.0 promises to suck less. They are ditching Chromium for new Edge technology.

That's the 9s one they are advertising :)

Reply on news.ycombinator.com