PATCH: code cleanup

[rkmr.em at gmail.com]

It looks like a well needed patch!! I am going to apply it to mine. I dont
have commit on repo either!!!
Committers pl. take a look!!


On 4/6/07, Tim Yardley <liquid at haveheart.com> wrote:
>
>  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/75e76950/attachment.htm