Hello Memcached community! Just wanna share that I've created Why native? <https://github.com/jefyt/memcached-windows/wiki/Why-native%3F> wiki that contains basic comparison of the native port with the Cygwin alternative. Please take note of the test environment. Results will likely differ depending on environment. Summary:
1. Standby CPU usage of native is *< 0.01%* while Cygwin *> 0.50%* 2. While testing, CPU usage of native is *< 25%* while Cygwin *> 35%* 3. Cygwin's CPU time (rusage) total is *>70% *more than native 4. Native's throughput and speed are at least *7%* better 5. Cygwin's latency is at least *10%* more than native 6. Native's created threads stays at *10* (same upstream) while Cygwin created *18* before test and added *2* after test (*20* total). Again, this is just basic comparison executed with default args on a basic Windows laptop with an Ubuntu running on its VirtualBox. Regards, Jefty On Sunday, April 5, 2020 at 12:47:04 PM UTC+2, Jefty Negapatan wrote: > > Hi Dormando, > > Thanks for at least for considering this new port. > > Often the patches are huge/unwieldy or simply replace code so it won't run > on anything _but_ windows. > --> I understand your concern. This is the reason why I have these basic > requirements for this port: > > 1. Codes (new and modified) *MUST* be guarded with prep macros/build > env (e.g. DISABLE_UNIX_SOCKET, _WIN32, mingw32). Building for non-Windows > target *MUST* just be same as the upstream as if no codes were > added/modified. > 2. Codes *MUST* build with latest GCC with Mingw-w64 > <http://mingw-w64.org/> both on Windows and *nix build hosts. CI build > is using *debian:testing* docker to take advantage of the latest GCC > (currently *9.3*) similar to cURL <https://curl.haxx.se/windows/>. > 3. Runtime dependencies *SHOULD* only be the Windows system libraries > similar to cURL <https://curl.haxx.se/windows/> where all dependencies > are statically linked for Windows. As you know Windows package management > is not similar to *nix where you can just easily install deps (libevent, > OpenSSL). So far, this is satisfied and the remaining unsupported feature > is SASL. > 4. And of course, it *MUST* passed the tests. > > > In that spirit, do you have any interest in finding what code can be > upstreamed to either minimize the size of the fork to something managable > longer term, or at least fiddle in that direction? My thought would be > (though again I haven't at all looked at what > you've done) is to break down the changes into small chunks to be > individually reviewed and upstreamed so that the fork simply shrinks with > time. There should be some changes that're easier than others to upstream. > --> I can do this. I'll just break down the changes into small chunks and > request for review. > > Thanks! > > Regards, > Jefty > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/d2279962-eed0-4174-abb0-95fd4716ca63%40googlegroups.com.
