Ciao, Il Gio, 31 Maggio 2012 3:25 pm, Marc Glisse ha scritto: > On Thu, 31 May 2012, Niels Möller wrote:
>> And then the question remains, are there systems and C libraries where >> free + malloc is significantly slower than realloc in common cases? > > I am afraid so. Experiments are needed, but my intuition tells me that for > small numbers (for large numbers, the cost of copying in realloc is anyway > small compared to whatever operation you are doing), free+malloc will be > significantly slower than realloc. I renewed the question because I was looking into mpq. In almost all cases (mpq_abs, mpq_get_den, mpq_get_num, mpq_inv, mpq_neg, mpq_set, mpq_set_den, mpq_set_num, mpq_set_z) I touched, the "whatever" operation is a copy, and we risk to spend almost half of the total time in the copy implied by realloc. Of course, those functions are not the most time-critical ones... I know there are other arguments, we might discuss about a possible change in the memory interface. The points I see: - should we ask for a fourth function (alloc, free, conservative_realloc, nonconservative_realloc)? >> (Speaking of allocation, I also wonder what to do about the problem >> described in >> http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html, >> there were no replies at the time). - should we keep the old_size parameter in the interface? > Related: I was always unhappy about the order of the reallocation function > arguments. malloc and free can be used by gmp (just ignore the old size > passed as last argument) but realloc needs a wrapper. - should we change the order of parameters? Best regards, Marco -- http://bodrato.it/papers/ _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
