- Even if it's JS, just-js make almost no use of dynamic memory allocations.
- The authors rewrote himself a postgresql driver that support batching request.
- it wraps high performance c++ libraries
Even if the techempower implementation is far more verbose and complex than mainstream JS framework, the amount of work behind just-js and its preformances are just impressive!
I don't understand why when you say "I have covid" people want the proof that you have it and ask you "did you do the test ?".
I personally think I got it twice and never did any test. Just had symptoms I never had before in the 2 waves we had in france, just after meeting persons who also got seek at the same time. This is enough coincidence for me to think I have covid.
I also think that this reasoning may be more accurate that the official not very accurate covid tests.
Doing this reasoning myself also saved me money and the 4h waiting queue to do the test (the last thing I want to do when I have fever).
On the other side, I know people who had symptoms, tested negative (and trusted the test) and still when out to meet (and maybe contaminate) friends or colleagues.
or just run npm test / make test locally without setting up anything. But I feel like writting the tests takes usually more time than setting up CI/CD.
Very interesting, I really think that http APIs are just a user management layer that could be easily abstracted away now that we can do so many things client-side.
How do you handle permissions ? or how do you pervent a clients to erase the database ?
Projects using templates and heavy metaprogramming often see most of the compile time spent in template instantiation, not in link time. For this kind of projects I think this would help.
Great that C++ compiler teams are working on reducing C++ compile time. The next great feature I think would be a game changer is caching the result of compilation (templates and binary code). A fine grained cache acting at the level of a line (or a function if it's too hard) would save an incredible amount of time to C++ devs, while also simplifying build systems. This would also stop engineers from losing days trying to speedup their build.
Is there any doc about how this caching is implemented ? I still don't understand why we need to feed this dependency array to have an up to date version of the count variable.
This is the official continuous techempower benchmark, run by techempower on the exact same environment than the techempower "official rounds". The only diff I'm aware of is that there is more manual review and check for rounds than for continuous benchmarks. Here is more info about it here:
We have already seen tremendous social adoption of the continuous benchmarking results. For selfish reasons, we want to continue creating and posting official rounds such as today's Round 16 periodically. (Mostly so that we can use the opportunity to write a blog entry and generate hype!) We ask that you humor us and treat official rounds as the super interesting and meaningful events that they are.
Jokes aside, the continuous results are intended for contributors to the project. The official rounds are less-frequent snapshots suitable for everyone else who may find the data interesting.
My motivation in writing yet another web framework was to get pure performance while providing maintainability of more dynamic languages. Check the implementation of lithium, it is one of the most concise implementation of TFB: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
The frameworks are downloaded by dockerfiles provided by the framework maintainers, and since there is hundreds of frameworks, this is a bit tedious to manually get all URLs...
But anyway, I'm pretty sure all framework maintainers will rush to provide all the info Techempower need to add a link to their website..
yes, it has been discused already to increase the number of connections. But still, several thousands of simultaneous connections is still ok for the best performing frameworks...
Sadly seastar has no implementation of this benchmark. I had a quick look at the website and it seams that seastar is much more low level (it does not provide a http parser) and more generic that lithium, which is focused on simplifying the writing of HTTP APIs.
The epoll code use is very small, few hundreds of LOC (but is at the very center of the framework since it runs the event loop), actually writing it from scratch was better to understand the mechanism, to optimize it and to adapt it for non blocking sql.
I would say the profiler output is the best source of information. Lithium is not using black magic at all. Actually on large framework like lithium, performance problems come more from obvious errors that get hiden in the quantity of code than in code that you did not crazy optimize.
Only the profiler will tell you if there is a hidden malloc that is slowing down all the rest, or a inefficient datastructure, or ...
There is probably lot of non optimized code in lithium, it just has no impact (or if it has I still has to find it).
That said, for other kind of software (usually more CPU bound), going down to assembly or using SIMD can be the only way to get good perfs.
Even if the techempower implementation is far more verbose and complex than mainstream JS framework, the amount of work behind just-js and its preformances are just impressive!