As I expected the gain regarding the only applet is not big (if any).
But to develop common interfaces is definitely an important task in
the long run. Even if not applied directly one may use config_*()
prototypes inline with some code thrown, and still the logic would
retain and would provide the right results. There would be no need to
reinvent the wheel.

The first and the second TODOs tell a function for getting a possibly
continued line is needed. The third indeed one is to be thought of.

Testsuite did not worked out of box since I use to compile BB outside
its source tree (O=../build parameter to make). To be done.

I'll attack crond today

--
Vladimir


2008/7/14, Denys Vlasenko <[EMAIL PROTECTED]>:
> On Sunday 13 July 2008 22:11, [EMAIL PROTECTED] wrote:
>> Attached is a trident of:
>> * one-go-read config_*() (443 bytes)
>> * stdio-based config_*() (504 bytes), appox. 2 times slower
>> * mdev patch which make use of them (-90 bytes)
>>
>> I consider a good start to shave 90 bytes from such a well-coded applet as
>> mdev.
>
> Well, the total result is:
>
> function                                             old     new   delta
> config_read                                            -     416    +416
> config_open                                            -      43     +43
> find_main                                            406     418     +12
> config_close                                           -       9      +9
> ...
> next_field                                            32       -     -32
> make_device                                         1269    1119    -150
> ------------------------------------------------------------------------------
> (add/remove: 3/1 grow/shrink: 6/7 up/down: 504/-198)          Total: 306
> bytes
>
> Not too good.
>
> Also, "cd testsuite && ./runtest mdev" reveal that there are two
> regressions.
> (One is actaully false positive, but the other seems to be real).
>
>> Who is next?
>
> Please see attached version. It's still your algorithm, just somewhat shrunk
> both in code size (-20 bytes) and memory consumption. A few TODOs indicate
> how it can be speeded up. (I do not require you to work on these TODOs).
>
> Can you deal with mdev testsuite regressions? NB: you need to build busybox
> statically for mdev tests to work.
>
> As to "what is next", I think maybe crond...
> --
> vda
>
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox

Reply via email to