rebased fixes for 1.4.x codeline #2

Closed
wants to merge 6 commits into
from

4 participants

@lindner

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.

Paul Lindner and others added some commits Dec 28, 2009
@dustin
memcached community member

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.

@lindner

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.

@trondn
memcached community member

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?

@trondn
memcached community member

Any updates on this?

@lindner

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...

@zwChan zwChan referenced this pull request Apr 24, 2014
Closed

solution for Issue #260: #67

@dormando
memcached community member

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?

@dormando
memcached community member

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.

@dormando dormando closed this Jun 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment