0

I develop on windows 64bit with VS2015.

I used a custom logger but it suffered from heap fragmentations. I found log4cpp library. According to the source code it uses std::ostringstream internally. My questions:

  • I think my main question is can I use log4cpp safely and not worry about heap fragmentations?
  • The first question probably leads to the questions how does std::ostringstream work internally to prevent heap fragmentations? Does it have multiple buffers in stack for small strings or does it always allocates a new string in heap?
theateist
  • 13,879
  • 17
  • 69
  • 109
  • Why did yours fragment? Custom allocator with a pool could easily allow you to fix that. – Retired Ninja May 01 '19 at 22:03
  • @πάνταῥεῖ, I updated my title. I think my main question is, from people experience can I use log4cpp safely and not worry about heap fragmentations when build with VS2015 on windows? – theateist May 01 '19 at 22:04
  • @RetiredNinja, you're probably right, but without getting to the details, I would like to use log4cpp library for logging and just want to be sure that I won't get heap fragmentations. – theateist May 01 '19 at 22:07
  • How much logging are you doing that fragmentation is a problem? Fragmentation is normally only a problem with long-lived allocations and I'm not sure how a logger would have many of those. – tadman May 01 '19 at 22:13
  • @tadman, my application runs for several hours and havily uses logging framework. You might argue that I need a different design then, but it's not my code. So, my question is, based on your/someone's experience can I use `log4cpp` and not worry about the frag? – theateist May 01 '19 at 22:22
  • In C++, there are no guarantees about fragmentation. You could tell `std::ostringstream` to use a fixed length string. Allocate the string first, then pass to `std::ostringstream` (see constructor). Note: you'll have to ensure that the logging text does not exceed the length of the string. – Thomas Matthews May 01 '19 at 22:25
  • @ThomasMatthews, I want to use `log4cpp` framework! I don't think I need to deal with all that fixed length since it's a framework. So, my question is, based on someone's experience can I use log4cpp and not worry about the frag? – theateist May 01 '19 at 22:27
  • 1
    I can't speak for fragmentation because I didn't have an issue so I didn't care. That said, I used it in an app that's part of the backend for a huge game and had no issues. I'm having a hard time imagining a way a logger could cause a fragmentation problem too, logs are ephemeral. – Retired Ninja May 01 '19 at 22:34
  • It's not the run-time of the process that matters, but the lifetime of the individual allocations. Fragmentation normally occurs when you have a pathologically abusive allocation strategy, often unintentionally, where the heap can't be cleaned up because there's inconvenient and long-lived allocations in it. Loggers should be using very few allocations, just the usual file-streaming ones, and everything should be short-lived. – tadman May 01 '19 at 22:41
  • 1
    I'd test your logger under the most demanding conditions possible, like hammer it as hard as you can for 20+ hours, to see if it causes any fragmentation. My guess is it won't. This is usually the fault of other code that has lots of awkward, long-lived allocations. If you need to implement a logger, use a [ring buffer](https://en.wikipedia.org/wiki/Circular_buffer) so you allocate once and use that for everything. This is how a lot of "zero allocation" libraries do it. – tadman May 01 '19 at 22:41

0 Answers0