Messages in this thread | | | Date | Wed, 1 Nov 2006 17:17:48 -0500 | From | "Holden Karau" <> | Subject | Re: [PATCH 1/1] fat: improve sync performance by grouping writes revised again |
| |
Hi Jörn,
If I do c_bh = kmalloc(blah); err= -ENOMEM; if (!c_bh) goto error; //here err = -ENOMEM ... do some stuff... error: return err;
It will return -ENOMEM, no? I mean I could set err back to 0 and do something like:
c_bh = kmalloc(blah); err= -ENOMEM; if (!c_bh) goto error; err = 0; ... do some stuf... error: return err;
At first glance, at least for me, I'd be scratching my head when I looked at that.
Also given that this error state is to be an exception not the rule, if what Phillip suggests is correct, than it would actually be a tiney be slower. So, all in all I'd rather leave it the way it is :-)
On 11/1/06, Phillip Susi <psusi@cfl.rr.com> wrote: > I think this is getting into micro-optimization, which is usually bad. > Also moving the assignment of err outside the body of the if only > results in slightly faster code in the case where there is an error, > since you can test and _maybe_ conditionally jump directly to the error: > label if it is not very far away. With the assignment in the body, the > conditional jump must jump to the assignment followed by an > unconditional jump to the label. > > In other words, the only time this micro optimization will be of benefit > is if you are erroring out most of the time rather than only under > exceptional conditions, AND the error label isn't too far away for a > conditional branch to reach. In other words, just don't do it ;) > > Jörn Engel wrote: > > On Wed, 1 November 2006 13:02:12 -0500, Holden Karau wrote: > >> On 11/1/06, Jörn Engel <joern@wohnheim.fh-wedel.de> wrote: > >>> Result would be something like: > >>> c_bh = kmalloc(... > >>> err = -ENOMEM; > >>> if (!c_bh) > >>> goto error; > >> That wouldn't work so well since we always return err, > > > > I don't quite follow. If the branch is taken, err is -ENOMEM. If the > > branch is not taken, err is set to 0 with the next instruction. > > > > Both methods definitely work. Whether one is preferrable over the > > other is imo 90% taste and maybe 10% better code on some architecture. > > So just pick what you prefer. > > > > Jörn > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
-- Cell: 613-276-1645 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |