[Nfd-dev] Avoid inline functions to reduce code size bloat

[Junxiao Shi]

Hi Alex

1. Yes, this guide is advisory. However, advisory rules can't be ignored
without justification.
Advisory rules can be interpreted as RFC 2119 "SHOULD" level: "there may
exist valid reasons in particular circumstances to ignore a particular
item".
A justification is needed for each function that SHOULD be non-inline but
is decided to be inline.

2. As said in C++ Dos and Don'ts, when the function is longer than a few
instructions, compiler won't inline it.

3. As benchmarked, adding two new compilation units for name and
name-component and eliminating inline functions in these two types result
in a reduction of total compilation time.
What are other reasons against additional compilation units?

4a. Having other work to do isn't an excuse of ignoring previous decision
without justification.

4b. Please cite a Bug that is solely caused by moving the definition of a
non-template function into .cpp.

Yours, Junxiao
On Jan 31, 2015 11:38 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> The cited page make an upfront disclaimer "A NOTE ABOUT USAGE: Unlike the
> style guide, the content of this page is advisory, not required.  You can
> always deviate from something on this page, if the
> relevant author/reviewer/OWNERS agree that another course is better.”
>
> As a first point.  I don’t agree with everything stated in this guide and
> it is advisory at most.  You cannot require every single implementation to
> follow some specific rule.
>
> Second.  I don’t agree with “code bloat” problem.  Yes, I saw your tests
> long time ago and they showed some correlation between listing code inline
> and not.  It is always compilers decision anyways to inline something or
> not to inline something.  I believe, when it is not in the header, the
> compiler simply don’t have a chance to make optimizations if it deem them
> appropriate.  Use size-oriented optimization, where compiler should be
> smarter about inlining.
>
> Third.  Putting (some) implementation in the header and not putting it has
> its own tradeoffs.  When “hiding” in .cpp it reduces how much stuff is
> included, but also requires creation of additional compilation unit.  In
> some cases extra compilation unit make sense, in some cases it is not.  I’m
> against defining any specific rules for that, as it is developer’s
> discretion.
>
> Finally.  There are so much other work to do.  We have >180 open redmine
> issues for NFD and ndn-cxx.  I’m completely against touching the code that
> has been working, even if we do modifications.  I can cite a couple of
> examples when such changes resulted in serious bugs.
>
> —
> Alex
>
>
> On Jan 31, 2015, at 10:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Dear folks
>
> Back in June, in issue 1694, I have pointed out that ndn-cxx has a
> tendency of over-using inline functions.
> According to C++ Dos and Don'ts
> <http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers> from
> Chromium project, using too much inline functions creates additional work
> for the linker, because every file that includes those headers would emit a
> version of an inline function in the object file (.o), and the linker has
> to eliminate those duplicates.
> There's also evidence that inline functions can lead to binary size bloat,
> which is bad news of devices with small memory or storage, such as home
> routers and IoT gadgets. Even if ndn-cxx can fit into those devices,
> bloated binaries will consume precious memory space, and reduce available
> memory for ContentStore.
>
> A decision was made in 20140708 conference call
> <http://redmine.named-data.net/issues/1694#note-6> that we should stop
> adding new inline functions unless they are trivial getters/setters, but
> fixing old code is low priority.
> Of course, if a function is template, and all possible template parameters
> are not known in advance, it can be inline.
>
>
> During the review of issue 2183, I suggested Change Owner to move inline
> functions into .cpp, as per the decision above.
> However, this suggestion was rejected.
> The reply was "whatever you saying. I'm refusing to do change here". No
> valid reason is given with this reply.
>
>
> To finally resolve this and similar disputes, I request a review on the
> decision about inline function usage.
> Please give your opinion about where inline functions should be used,
> along with necessary reasons and citations.
>
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/78f171cb/attachment.html>