Am 02/07/2011 09:37 AM, schrieb Øyvind Harboe: > On Mon, Feb 7, 2011 at 9:27 AM, Mathias K. <kes...@freenet.de> wrote: >> Hello, >> >> On 07.02.2011 09:09, Øyvind Harboe wrote: >>> What impact would it have to make this an >>> inline fn? >> I think there is no need to declare this "big" function as inline. This will >> only increase the code size. > To the point where it matters? > > I think clarity and performance matters much more > than code-size, right? On what kind of system?
On embedded CPUs with small caches, inlining will usually slow down the code because less of it fits inside the code cache - on those systems, -Os is usually faster than the more aggressive optimization levels that do more inlining. I vote to keep the code readable and only inline when there is a real *noticeable* gain, not just because profiling shows that it is faster. (that does not mean I object against the original patch: speeding up the implementation by optimizing the code is fine, as long as it does not hamper maintainability). cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
