2

I'm considering using boost::function in my implementation of a timer manager. At schedule timer a boost::function will be passed and at the timer expiration the callback will be executed. Times will be scheduled/canceled at a vey high frequency (~1000 actions/sec).

But I'm concerned regarding the amount of heap memory boost::function may use.

I know for example that boost::asio uses boost::function a lot, while performance requirements for the library are probably very high.

What do you think?

rubenvb
  • 74,642
  • 33
  • 187
  • 332
dimba
  • 26,717
  • 34
  • 141
  • 196

2 Answers2

3

It's unlikely in my opinion that the overhead of boost::function will be the gating factor in timer management code.

Getting the timer queue, locking and signalling waiting threads correct and efficient is a much better use of your brain cycles. Perversely, that's another argument in favour of boost::function or similar to avoid headaches with 'raw' callbacks.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
2

boost::function is a fairly small object. Might be all of 2-3x the size of a normal function pointer, if any.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • I'm not concerned about the size of allocated data, but rather about new/delete itself – dimba Nov 29 '10 at 19:39
  • @dimba - you are going to have to `new` something to track pending timers anyway, if you are careful the functor memory can be included in that can't it? – Steve Townsend Nov 29 '10 at 20:13
  • @Steve I don't sure I understand what you mean. User will have API like ScheduleTimer(boost::function<>, ...), so boost::function<> already allocated by user. Can I do it different way? I'm using 3rd pary library for timer managment (ACE) which enables to store void* for each active timer, so I'll need to store store pointer to boost::function<>. Can I use it somehow to prevent some memory allocation? – dimba Nov 29 '10 at 20:49
  • In that case, you should be able to either share the user's copy, or else copy it, but the user will not need their copy any more. This is a wash, whichever way you look at it - net effect = 1 functor on the heap during timer handling. I just wondered if you could include this in the timer correlation structure, to avoid using a heap-based struct that has a pointer to functor. – Steve Townsend Nov 29 '10 at 20:52