| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Once I ran some microbenchmarks and it wasn't clear if calloc() was faster than malloc()+memset(0). It should, but I failed to measure such speedup. Well, the change is correct ;-) https://bugs.python.org/issue21233#msg217253 Sadly, pymalloc allocator has no efficient of calloc yet: it's just malloc+memset(0) in internally. But it should help for allocations larger than 512 bytes (not using pymalloc). |
Sorry, something went wrong.
|
My concern wasn't speed, but in DRY and minimization of code. Still, a speedup would be nice if it happens. |
Sorry, something went wrong.
|
If the compiler sees the memset, it may be able to generate more efficient zeroing instructions inline. I imagine it would be hard to prove any different in CPython, though. I like calloc because it provides a way to avoid some integer overflows. |
Sorry, something went wrong.
|
The memsets are still there. They're just inside the *calloc functions. |
Sorry, something went wrong.
For memory allocations larger than 512 bytes, libc malloc() is used and the libc is free to avoid memset if it knows that the memory is already initialized with zeros. I expect that memory allocated by mmap() doesn't provide uninitialized memory for example. This change should not make slower, but it's ok if it doesn't make Python faster neither. I expect that in some cases, it may be faster. But I don't bother enough to run exhaustive microbenchmarks ;-)
Sure, that's a cool enhancement since we had many security issues related to integer overflow in the past :-/ |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This consolidates a number of malloc+memset function calls to use their calloc-based equivalents.
https://bugs.python.org/issue39943