X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:reply-to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=aJZHgUhnR/rr5SGy
	OIJw2yTQ7lkp63SIgQV14sJFyBL+dll0J2Lbkk5r5Gq8j3/Oc+yUafDtS+mLuLPQ
	jOKOj7aypweUZu3BygjZfuB6A3Bpt+lFs/j2fraMRQU6mraP4gyTB7cnEakcV3RR
	8bJghnquFZit5sslf+9pR4kqW/k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:reply-to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=fyCKnXBPconLO7gqSi96jS
	dYYXY=; b=LnacIWLZq7lnvKptVoWt6+cwpFGSwoOTIf1EaVy+E+PySGUKv1Zmkl
	lZsWsu1KObgey0yxJwSW2uI51Fs80Gkru2O8I5bl2gXnr2R4fQLgDRqjQhoivQBp
	77bb1k7Ku8RhJCc8+vjAw9xwdbq+o2GpB+6w94aadwyZ0aWQawiys=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1903
X-HELO: mail-it0-f50.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:subject:to:references:reply-to:from:message-id         :date:user-agent:mime-version:in-reply-to:content-language         :content-transfer-encoding;        bh=D1h4A42p7Tpk2f5jt/kdo5CQoYV7w9/ltStonVfc85w=;        b=Xt8OuYl4wnZDrHCnZjSi9JBZWVV/1vWxVRPw2u8H6OV9Dz9xKRp2n4t7AP2i6nqAac         5cAuWTM8zHx7pmyPkxRUGx4q4Hr74s40TwGQC4uyiBmvARMOOW52vEHf5S2jU4WODvWs         pDzZ8jWKxhu+0Uum9i43grO2wNC9fjM4E8ve0lZGRBHOTVnph2tLFqzRGZdSCRMj58Gl         RCZNmKkl94PFex4r/2PMdbz0EhaZPiIc/jEWrMM3FzLHHLW/lMSgz27tEZkgVGaaekmM         MRnx4LEHv19Ucz4CWRd6UNyKFjWB0Ux0kV+Vd5em4c+lmmyj571d+v1+IOWq/MQ/Co5e         v7ZA==
X-Gm-Message-State: AKwxytdhdB5v5Q3SUf4wrQ/87XMhk+p9Ma+i5qayrWrWdYn8gQ6fBa5C	W456/16WKXZy8RVioatX/s7EeQ==
X-Google-Smtp-Source: ACJfBov8E8luzbuXhM7T7pBY11zjzh6JsWFa69JWfYoXSUbACMR+mMojqvBuhgj101zHXwm19WRTww==
X-Received: by 10.36.165.79 with SMTP id w15mr5955711iti.127.1515796461090;        Fri, 12 Jan 2018 14:34:21 -0800 (PST)
Subject: Re: calloc speed difference
To: cygwin AT cygwin DOT com
References: <CAD8GWsvxzFe0dPnxO-odTY+EG5XOAApLjcOSN5d7vXhtLW0GmQ AT mail DOT gmail DOT com> <46515148-9f8e-6eae-69f9-9bf20921097a AT t-online DOT de> <20180112143339 DOT GE24623 AT calimero DOT vinschen DOT de> <b7ab3fe3-fa81-432d-33ad-9c0d7948b044 AT gmail DOT com> <20180112204149 DOT GF24623 AT calimero DOT vinschen DOT de>
Reply-To: cygwin AT cygwin DOT com
From: cyg Simple <cygsimple AT gmail DOT com>
Message-ID: <3acfae95-e62b-40d5-d094-44e651dd6b79@gmail.com>
Date: Fri, 12 Jan 2018 17:34:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180112204149.GF24623@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

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
>>>> later.
>>>>
>>>> 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.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple