[libcamera-devel] [PATCH] cam: convert to libfmt

[Tomi Valkeinen]

On 10/05/2022 17:20, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Tue, May 10, 2022 at 05:05:05PM +0300, Tomi Valkeinen wrote:
>> On 10/05/2022 16:22, Laurent Pinchart wrote:
>>> On Tue, May 10, 2022 at 10:16:17AM +0300, Tomi Valkeinen wrote:
>>>> This is just a conversation starter, not for merging. I really like
>>>> libfmt, and I really hate the C++ stream-based string formatting. libfmt
>>>> is the first library I add to any new C++ project I make.
>>>
>>> You've got it wrong. The first library you should add to any new C++
>>> project you make is libcamera :-)
>>>
>>>> You can find more information about libfmt from:
>>>>
>>>> https://github.com/fmtlib/fmt
>>>> https://fmt.dev/latest/index.html
>>>>
>>>> This patch is just a crude conversion with ugly macros to showcase what
>>>> the formatting code might look like.
>>>>
>>>> libfmt pages suggest that libfmt would be faster and smaller (exe size)
>>>> than iostreams, but for the size it didn't seem to be true in cam's case
>>>> as the tests below show. However, simple prints did reduce the exe size,
>>>> but the few more complex ones increased the size.
>>>>
>>>> Size tests with gcc 11.2.0-19ubuntu1
>>>>
>>>> - Without libfmt
>>>>
>>>> debug		3523400
>>>> debug lto	3269368
>>>> release		223056
>>>> release lto	172280
>>>>
>>>> - With libfmt
>>>>
>>>> debug		4424256
>>>> debug lto	4143840
>>>> release		303952
>>>> release lto	252640
>>>>
>>>> Above shows that cam's size clearly increases with libfmt. However, the
>>>> increase really comes only from one case, the use of fmt::memory_buffer
>>>> and std::back_inserter.
>>>
>>> Is this because libfmt is a header-only library ? What if it is built as
>>> a shared object, what's the impact on code size in cam ?
>>
>> libfmt supports header-only, but it's not header-only here.
>>
>>>> Converting that code to use fmt::format() and
>>>> naive string append gives:
>>>>
>>>> release with string append	233680
>>>> release lto with string append	186936
>>>
>>> What's the impact of switching to string concatenation on runtime ?
>>
>> What do you mean?
> 
> I mean what is the impact on CPU usage of using the "naive" string
> append, compared to std::stringstream or fmt::memory_buffer ?
> 
>>> Would you consider the option of keeping std::stringstream ?
>>
>> You mean formatting mostly with libfmt, but sometimes with streams? Or
>> using libfmt but appending the formatted string to stringstream?
> 
> Mostly using fmt::, but using std::stringstream without
> fmt::memory_buffer when a string needs to be assembled. I'm not saying
> it's necessarily a good idea, just wondering.

I did test using fmt::format() and assembling the result to 
std::stringstream, and that does keep the executable size down.

So somehow fmt::format_to() seems to pull in a lot of code. I got a 
comment on libfmt gitter: "Normally format and format_to are compiled to 
the same underlying calls where the iterator is type erased.". I'm 
currently inclined to believe it's a bug.

  Tomi