search

c9s / r3

libr3 is a high-performance path dispatching library. It compiles your route paths into a prefix tree (trie). By using the constructed prefix trie in the start-up time, you may dispatch your routes with efficiency
http://c9s.github.com/r3/bench.html
MIT License
816 stars 83 forks source link

zcalloc confusion #104

Closed njlr closed 6 years ago

njlr commented 7 years ago

I am trying to use r3 and zlib in the same project. The problem is that both seem to define a zcalloc function: 

c++ link
stderr: duplicate symbol _zcalloc in ... 
... etc

Can I configure r3 to not use its own zalloc, and instead use the one specified by zlib?

njlr commented 7 years ago

I am using version 0d78599a57aa7499b5f8f398ddf7860d7434dafd.

njlr commented 7 years ago

As a work-around I can force jemalloc with -DUSE_JEMALLOC=1, however it would be nice to use one zcalloc everywhere.

msteinert commented 6 years ago

I'm having the same problem at the moment. Looking through the source I'm struggling to understand why zmalloc is used here. It appears to be from the Redis source and adds functionality to track the total amount of memory allocated, however r3 doesn't appear to access the functionality in any way (it just uses it as a malloc wrapper).

c9s commented 6 years ago

Initially, i choosed jemalloc as the memory allocator.

However a Japanese guy thought zmalloc is faster than all the memory allocator. A PR was merged.

As the time goes by, I started thinking that we should keep the design and the implementation simple.

So it’s very open. Proposals are welcomed.

Mike Steinert notifications@github.com於 2018年7月1日 週日，02:15寫道：

I'm having the same problem at the moment. Looking through the source I'm struggling to understand why zmalloc is used here. It appears to be from the Redis source and adds functionality to track the total amount of memory allocated, however r3 doesn't appear to access the functionality in any way (it just uses it as a malloc wrapper).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/c9s/r3/issues/104#issuecomment-401557554, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGziREyG8_iyCI2DUyiGx_UpBwk5JTks5uB8A0gaJpZM4Pr5xF .

msteinert commented 6 years ago

Thanks for the background information. I suspect that zmalloc is actually slower since it really just adds some bookkeeping overhead to the standard allocator.

As for other allocators (like jemalloc or tcmalloc), personally I would prefer if that was left as a decision when linking an application. I don't really want a library forcing me to link with an alternative memory allocator.

I would propose just reverting back to plain old malloc/free et. al. I'll put together a PR if you like. I've started working to that end a bit by cleaning up the CMake files:

https://github.com/c9s/r3/pull/113