Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
To me the most impressive recent example is a video editor developed for Haiku OS [0]. It fits on a 1.44MB floppy disk.
[0] https://github.com/smallstepforman/Medo
I used this one https://github.com/Sycnex/Windows10Debloater and yeah I had to heavily customize it and then I did need to re-enable something afterwords which I found on the github.
Basically what I did was I started with the default and then unchecked (or checked? I don't remember what the UI called for now) anything related to Xbox and the Store and I didnt have any issues.
I also did a comparison before and after and it was actually a pretty decent improvement. About a 10fps improvement over SteamOS and a Normal Windows 10.
For me the biggest incentive was being able to play xbox game pass games and not needing to worry about any compatibility issues with Proton which is why I went down that route.
But yeah your second part is very true. I feel, the impact is minimal if you are on a traditional PC. But on something with such limited resources like a Steam Deck, the difference can be going from 40 fps to mid 50's and a few more minutes of battery life.
But it isn't something I would recommend most people do. More just kinda pointing out that with the effort I think Microsoft could make a lean Windows really just by taking a look at what is actually necessary to be run for specific tasks.
Not serving, but handling 2100k requests. Your skepticism is rightly placed, as the HTTP protocol is yet an example of an inefficient protocol that nonetheless is used as the primary protocol on the internet. Some webservers[1] can serve millions of requests pr. second, but I'd never use HTTP in code where efficiency is key.
No, I'm talking about handling requests. In this particular case, requests (32 to 64 bytes) were flowing through several services (on the same computer). I replaced the processing chain with a single application to remove the overhead of serialization between processes. Requests were filtered early in the pipeline, which made a ~55% reduction in the work needed.
Requests were then batche into succinct data structures and processed via SIMD. Output used to be JSON, but I instead wrote a custom memory allocator and just memcpy the entire blob on to the wire.
Before: No pre-filtering, off-the-shelf databases (PSQL), queue system for I/O, named pipes and TCP/IP for local data transfer. Lots of concurrency issues, thread starvation and I/O bound work.
After: Agnessive pre-filtering, succinct data structures for cache coherence, no serialization overhead, SIMD processing. Can saturate a 32 core CPU with almost no overhead.
[1] https://www.techempower.com/benchmarks/#section=data-r13&hw=...