Tbh, I don't think it is comparable to this project. A better alternative for Java would be Quarkus or Micronaut, ones that can compile to native using GraalVM.
The reason I did this comparison was to try to better understand what is in this project as I may consider using it, not to compare to Java performance wise.
How is that an advantage ? either you have N overloads doing manually what templates do automatically, or you have indirection and the implied performance loss
Those few seconds can add up very quickly when you’re making incremental changes and have to keep recompiling. I ended up having to write non-template wrappers for all my ASIO stuff and compile them as a separate object file, in order to keep my workflow manageable. Building that one object file would double my total build time.
I've actually done that all day long, at most it takes 3-4 seconds between code editing and the app / test running, I'd definitely not trade faster build times for something else in that case, especially when my IDE highlights errors when I type which greatly reduces the need for constant rebuilds.
At first we used pthread only. But after the windows branch was added, we have to make it compatible with windows and standard <mutex> was used in the some shared codes.
Codes in the "kernel" folder are for Linux only, and some of them are C.
Yes. We have applications that use all this clients. This framework supports the backend development of a pretty big industrial search engine, and we tend to build very large backend applications. And as a very light-weighted library, it's also used as a simple asynchronous MySQL client, or a kafka client. And the most often, an http server or client.
27 comments
[ 3.9 ms ] story [ 72.7 ms ] threadhttps://sparkjava.com/
Tbh, I don't think it is comparable to this project. A better alternative for Java would be Quarkus or Micronaut, ones that can compile to native using GraalVM.
I really do need to play with GraalVM.
For example src/manager/DNSCache.h use std::mutex but src/kernel/Executor.h use pthread_mutex_t?
That's an interesting selection. Do you have particular problem spaces in mind?