This is the mail archive of the
mailing list for the Cygwin project.
Re: calloc speed difference
On 1/12/2018 3:41 PM, Corinna Vinschen wrote:
> On Jan 12 14:59, cyg Simple wrote:
>> On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
>>> On Jan 12 15:06, Christian Franke wrote:
>>>> Timing [cm]alloc() calls without actually using the allocated memory might
>>>> produce misleading results due to lazy page allocation and/or zero-filling.
>>>> MinGW binaries use calloc() from msvcrt.dll. This calloc() does not call
>>>> malloc() and then memset(). It directly calls:
>>>> mem = HeapAlloc(_crtheap, HEAP_ZERO_MEMORY, size);
>>>> which possibly only reserves allocate-and-zero-fill-on-demand pages for
>>>> Cygwin's calloc() is different.
>>> But then again, Cygwin's malloc *is* slow, particulary in
>>> memory-demanding multi-threaded scenarios since that serializes all
>>> malloc/free calls.
>>> The memory handling within Cygwin is tricky. Attempts to replace good
>>> old dlmalloc with a fresher jemalloc or ptmalloc failed, but that only
>>> means the developer (i.e., me, in case of ptmalloc) was too lazy...
>>> busy! I mean busy... to pull this through.
>>> Having said that, if somebody would like to take a stab at replacing
>>> dlmalloc with something leaner, I would be very happy and assist as
>>> much as I can.
>> Corina, how reliable is the Cygwin time function on a non-Cygwin
>> executable? Isn't this a comparison of apples to oranges?
> I wasn't comparing, in fact. I was just saying that Cygwin's malloc
> is slow, partially because dlmalloc is not the fastest one, partially
> due to the serialization overhead in multithreading scenarios.
No, but the OP *is* doing a compare. From what I remember doing a time
comparison of a non-Cygwin app compared to a Cygwin app isn't really a
logical comparison. Even if the two were a Cygwin app multiple runs of
the same app will show variance.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple