[LEDE-DEV] [PATCH 1/5] base-files: introduce /lib/functions/board.sh

[Roman Yeryomin]

On 2 May 2017 at 21:47, Felix Fietkau <nbd at nbd.name> wrote:
> On 2017-05-02 20:31, Roman Yeryomin wrote:
>> On 2 May 2017 at 20:46, Felix Fietkau <nbd at nbd.name> wrote:
>>> On 2017-05-02 19:32, Roman Yeryomin wrote:
>>>> I just want to save maintenance time. As you admit it's already a
>>>> clutter. I'm trying to introduce some order.
>>>> Actually uci-defaults is another one which doesn't need 90% of
>>>> functions.sh (it only needs list_contains).
>>>> I would propose breaking down functions.sh into smaller files by
>>>> functionality, e.g. config/user/base/etc., together with optimizing
>>>> it's usage in other scripts.
>>>> Then /lib/functions.sh could become a meta include which includes
>>>> everything under /lib/functions/. It would be more logical and
>>>> structurally more right than including functions.sh from a script from
>>>> /lib/functions/.
>>> I think effectively you're making the whole thing slower and bigger at
>>> the same time. Processing the extra includes certainly results in extra
>>> syscalls and extra overhead, maybe even extra memory overhead.
>>> Additionally I'd say it does nothing to make the maintenance any easier.
>>> Please don't go that route, it really doesn't help.
>>>
>>
>> Why do you think so?
>> I've done tests, including few smaller files with only needed
>> functions actually is better than including one big file like
>> functions.sh.
>> Performance hit for bigger includes is more than from several small
>> ones. It's 10-20ms vs. 700-800ms over 100 iterations on ipq8065.
> Did you compare the case of including functions.sh with the function
> included vs the case of functions.sh + a separate file with the extra
> function, included by functions.sh?

Different scenarios, including that. All they show that what makes the
difference is the size of include, not count (up to sane numbers).
Last test I did was including 4 smaller files from /lib/functions
(summed lines are 310, close to functions.sh) vs. including single
functions.sh
Which I would say is pretty pessimistic scenario, most use cases will
do 1-3 includes.
And even then there is 500-600ms difference over 500 iterations.
If I take including board.sh vs. functions.sh (which is NOT including
anything further), then difference is 1500-1600ms.

>> And why do you say it will not make maintenance easier? Right now one
>> cannot understand what is what. If you name things it would become
>> more clear and easier to understand.
> In many cases there are dependencies between functions. If you split
> things up and need to include one file from the other, you could later
> end up processing the same files over and over again if you include
> multiple files (or even the top-level functions.sh).
> If you avoid those include statements in the include files themselves,
> the caller would have to know about the dependencies, which is not
> exactly better either.

It's just a question of clearing that up. And clear naming will help a lot.

>> Simply including a big
>> functions.sh doesn't say anything and IMO can only be a workaround,
>> when you don't know what you need. But even now this doesn't work
>> because there are separate files in /lib/functions/
> In this case we're talking about *one* *single* *one-line* function (if
> you leave out the unused board_model function, which you really should).
> How does having a separate include file make sense?

As I said, most target scripts need either board_name alone or a
fraction of functions.sh
Those which don't need board_name also need only a fraction of functions.sh

> As I mentioned earlier, if there are significant cases where you could
> avoid including functions.sh entirely, you could put this one-line
> function into a different one if you like, e.g. system.sh

I see such solution only increasing the clutter.
Many scrips now include functions.sh because authors simply didn't
want to look at the source and see that they don't need it. Even that
bad.
Some functions are completely unused.

Maybe it wasn't clear -- I'm volunteering to clean this clutter up.
But since it's spread all over the tree, I would do it step by step,
so it will take some time.


Regards,
Roman