PATCH: code cleanup

[Tim Yardley]

I don't have commit on the repo, so it is not checked in.  Anyone that does
have anything to say about the patch or body of the email?  
 
You are welcome to apply it if you'd like.
 
/tmy

  _____  

From: rkmr.em at gmail.com [mailto:rkmr.em at gmail.com] 
Sent: Friday, April 06, 2007 5:52 PM
To: Tim Yardley
Cc: memcached at lists.danga.com
Subject: Re: PATCH: code cleanup


is this checked in svn or do i need to apply this patch?
thanks

 
On 4/5/07, Tim Yardley <liquid at haveheart.com> wrote: 

All;

Attached is a patch against the multithreaded branch that cleans up spacing
issues bringing the codebase to a hopefully consistent style.  It also 
addresses -Wall warnings, some null checks (a TODO item iirc), and adds
asserts at the top of each function for any use of conn *c without checking
to see if c is NULL first.

Hopefully those asserts are not necessary as we all write perfect code... 
Right?  Anyway, that conn object is used and passed around enough that it
should be checked.

Note that there are a couple other areas that could be addressed on an
optimization level.  I addressed a few like multiple assignments to a 
variable where not needed, elimination of unused variables, value assignment
at initiation where it made sense, #ifdef where a function wont be used,
etc.

Other things that I noticed that could be addressed but require consensus: 
- optimization of the switch statements to leverage jump tables at
compilation
- focusing on popular default cases at the top of the switch to reduce
comparisons
- restructing switch statements if necessary to support that under 
different compilers (nesting the switches)
- visiting the usage of char vs int (byte alignment, powers of two
padding, etc)
- inlining some of the smaller functions (candidates would include some of
the item funtions, etc) 


A couple of the malloc cases in there looked potentially troubling
(arbitrary values chosen, and some potential other misallocations) but I
didn't spend the time to fully analyze them.  Does anyone have access to one

of the commercial source audit applications that would like to run memcached
through it?  If not, would anyone be interested in me persuing that avenue
with some of the vendors that have offered to run their commercial 
applications on opensource software?

Feedback welcome.

/tmy




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070406/56fa238d/attachment-0001.html