2016-04-20 12:46 GMT+02:00 Denys Vlasenko <[email protected]>: > On Tue, Apr 19, 2016 at 2:15 PM, Ron Yorston <[email protected]> wrote: >> The string of applet names seems ripe for compression: it has a limited >> range of characters and many common substrings. If the compression is >> too aggressive, though, the code required to handle it causes bloat. >> >> Recursively replace common pairs of characters with a character having >> its top bit set; the lower 7 bits being an index into an array of >> character pairs. This is only done if it results in a net saving, >> otherwise the current code is used. >> >> Provide an implementation of find_applet_by_name() which uses binary >> search: this reduces the number of string comparisons from an average >> of 27.9 per lookup to 7.7. This is important because of the added cost >> of expanding strings before comparison. (Compressing the input string >> is uncompetitive.) >> >> The new version of find_applet_by_name() is about 8% faster than the >> old one when strings aren't abbreviated. It isn't used in that case, >> though, as it's larger than the current implementation. >> >> When strings are abbreviated the new find_applet_by_name() is about >> 34% slower than currently. (All comparisons are for the default >> configuration.) > > Crazy :D
Is this really worth it? 34% slower may have a visible impact if applets are executed frequently. And then there's the added complexity. All of that for just some 500 bytes ? Guillermo _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
