On May 22, 9:49 pm, Bill Hart <[email protected]> wrote: > The main reason I recommended not to use that function in time > critical stuff is it is very, very slow (for reasons I don't > understand).
When the endianness and everything is right, mpz_import and mpz_export use MPN_COPY which calls copyi (on platforms where it exists), which should be similar to memcpy (if there is a significant performance difference between the 2 (and tune/speed can measure this easily), something is wrong). So do you mean the overhead (there is quite a bit, with several function calls and tests besides the allocation and copy) is too much when dealing with many small integers? Or do you mean there shouldn't even be a copy, exporting should just give a pointer to the internal data (and make sure no one calls mpz_clear) and importing should let a mpz take ownership of an existing buffer? (This type of passing buffers around works better with a garbage collector) Anyway, just from the name of the functions, it seems normal to try and avoid continually importing/exporting in a critical part of the code indeed... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
