Hi, Thanks for sharing this!
On Wed, Apr 8, 2020 at 10:56 PM Jefty Negapatan <jefty....@gmail.com> wrote: > 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 > > How do you measure the latency and throughput ? Regards, Martin > > 1. 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 > <https://groups.google.com/d/msgid/memcached/d2279962-eed0-4174-abb0-95fd4716ca63%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- --- 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/CAMomwMo5aDJkfmRmLm6T8kNdK3vxRhUTST7S5Q0wa%2B3UdKQ8UA%40mail.gmail.com.
