Hi, the boost pool documentation states ordererd_malloc(n) and boost::free(chunk, n) both take O(n). I tested it with a workload of a lot of n=1 and n=2 small allocations. Basically if I just use boost::malloc(2*base_size) even if i just need boost::malloc(base_size) the runtime is 1 min. With ordered_malloc(_)/boost::free(_,_) the runtime explodes (>> 30 minutes) (I terminated the program). Profiling it, one can see, that ordered_malloc dominates the runtime (83 % after a few minutes). Is this a known issue? Is the runtime of ordered_malloc in O(n), i.e. in O(c\cdot n), but the constant factor c is very huge? Best regards Georg Sauthoff
Georg Sauthoff wrote:
Hi,
the boost pool documentation states ordererd_malloc(n) and boost::free(chunk, n) both take O(n). I tested it with a workload of a lot of n=1 and n=2 small allocations.
Basically if I just use boost::malloc(2*base_size) even if i just need boost::malloc(base_size) the runtime is 1 min. With ordered_malloc(_)/boost::free(_,_) the runtime explodes (>> 30 minutes) (I terminated the program). Profiling it, one can see, that ordered_malloc dominates the runtime (83 % after a few minutes).
Is this a known issue? Is the runtime of ordered_malloc in O(n), i.e. in O(c\cdot n), but the constant factor c is very huge?
Best regards Georg Sauthoff
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Are you using Visual C++? You might have to disable its checked iterators if so.
On 2009-02-20, Raindog
Georg Sauthoff wrote: [..]
(I terminated the program). Profiling it, one can see, that ordered_malloc dominates the runtime (83 % after a few minutes).
Is this a known issue? Is the runtime of ordered_malloc in O(n), i.e. in O(c\cdot n), but the constant factor c is very huge?
Are you using Visual C++? You might have to disable its checked iterators if so.
No, I am using GCC 4.3.2 under Ubuntu. Best regards Georg Sauthoff
participants (2)
-
Georg Sauthoff -
Raindog