rebased fixes for 1.4.x codeline #2
Conversation
- use unsigned int, since this value can never be negative - use unlikely() macro to help with branch prediction logic - replace (settings.verbose > 0) with just (settings.verbose)
…n 64 bit systems - saves 32 bytes per connection
|
This feels like a lot of changes for a maintenance branch. I don't know think we can easily merge these changes up to the development branch. As most of this is performance, it seems like it's happening in the wrong place. |
|
Dustin -- how long have we been waiting for the next branch? These changes are fine and shouldn't affect what you're doing in your fork, plus they happen to fix an issue. Once you guys get serious about getting an alpha and a roadmap out the door is when I'll get serious about working off your engine branch. |
|
I'd rather see the 116 issue being replaced with a proper description about the current threading than just nuking away the document. The threading logic is the same in memcached, the problem is just that you can't disable it anymore... Apart from that all I can see from the change history is unlikely/likely changes.. what is the performance improvement in % for these intrusive changes? |
|
Any updates on this? |
|
Haven't had time to address your comments yet. Maybe this weekend. Been a bit consumed with the new job and tending to shindig lately... |
|
Never closed this since I'm curious if the likely/unlikely stuff actually makes a difference in performance tests... Four years is pretty bitrotted though. Sorry. guess I'll leave it open a bit longer before giving up? |
|
I pulled the gitignore change.. thought I had already. In the middle of refactoring a bunch of stuff which we can then re-profile and add likely/unlikely behind new macros. Updates to the connection code will happen soon after some code cleanup... will give a chance to reorder the structures, but more importantly idle connections won't hold onto buffers anymore. saves a lot more memory. closing this out. |
using the new per-class free chunk limiter and ignoring item age, we can now create a highly responsive page mover algorithm. It makes much fewer page moves than before and keeps more of the free memory target in each class. adjusts the per-class limits once per minute, and otherwise balancers by age.
issue #338 reported a memory leak in the init code. another non-issue, since it's a handful of bytes and that code path is only used in a couple of tests.
Hi, Finally got around to rebasing my 1.4.x branch
Note that this compiles under gcc 4.4 without problems and without the patch that was submitted for that fix.
Would appreciate it if you could take a second look at these patches.