From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id EE5303858D35; Sat, 10 Jun 2023 04:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE5303858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=axis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=axis.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1686369931; x=1717905931; h=from:to:cc:in-reply-to:subject:mime-version: content-transfer-encoding:references:message-id:date; bh=gl1RypKdmbCj45d3DHcPR7NrFwWCzzup7GtzJ+ex5Bk=; b=oCVARXbU8/YQC0Ho+bwD2LrNHFUrGJPdVPmgQcB9Rse9fqskjmnVb4x9 9NBD9GjAph2mW4F0Z6R5sUw7uvmcg6L+XL7/9twDMUyyGrScDYLxD2aR0 Sabzolb/LCZ3yMo8mY49MKF8RpIP5821HUUJ9YKfgbHEX7OYm/ZTTqJ3y oHNQC+QU5GqJ0XdT+dn+hlagzDxui/6TPEi5cBwUpy4gSZezq2MzP35lo g12CuTp5lSReH6OG9g/laSV4cKEGoz5kWgWdhq5dJsS6cESTeKhWqI3VR ojqfx48ku4SQM7OK0lgWDzp3G+iAC0f5rEronPp27FBXgSeBkcD8R57UI A==; From: Hans-Peter Nilsson To: Jonathan Wakely CC: , In-Reply-To: (message from Jonathan Wakely on Fri, 9 Jun 2023 21:40:15 +0100) Subject: [PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20230609162026.CC34320433@pchp3.se.axis.com> Message-ID: <20230610040528.1058420420@pchp3.se.axis.com> Date: Sat, 10 Jun 2023 06:05:28 +0200 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Thank you for your consideration. (Or is that phrase only used negatively?) > From: Jonathan Wakely > Date: Fri, 9 Jun 2023 21:40:15 +0100 > test01, test02, test03 and test04 should run almost instantly. On my system > they take about 5 microseconds each. So I don't think splitting those up > will help. Right. > I thought it would help to avoid re-allocating the buffer and zeroing it > again. If we reuse the same buffer, then we just have to loop until we > overflow the 32-bit counter. That would make the whole test run much > faster, which would reduce the total time for a testsuite run. Splitting > the file up into smaller files would not decrease the total time, only > decrease the time for that single test so it doesn't time out. > > I've attached a patch that does that. I makes very little difference for > me, probably because allocating zero-filled pages isn't actually expensive > on linux. Maybe it will make a differene for your simulator though? Nope, just some five seconds down (from about 10min 21s). > You could also try reducing the size of the buffer: > +#ifdef SIMULATOR_TEST > + static const streamsize bufsz = 16 << limits::digits10; > +#else > static const streamsize bufsz = 2048 << limits::digits10; > +#endif Was that supposed to be with or without the patch? Anyway; both: 606s. Only smaller bufsz: 614s. (All numbers subject to usual system jitter.) > test06 is the really slow part, that takes 10+ seconds for me. But that > entire function should already be skipped for simulators. Yep, we may have been here before... I certainly get a deja-vu feeling here, but visiting old email conversations of ours, it seems I easily conflate several similar ones. I see that here, test06 was always #ifndef SIMULATOR_TEST. > We can probably skip test05 for simulators too, none of the code it tests > is platform-specific, so as long as it's being tested on x86 we don't > really need to test it on cris-elf too. Thanks. Let's do that, then. The similar s/wchar_t/char/ test clocks in at "only" 3m30s, but I suggest treating it the same, if nothing else than for symmetry. Ok as below? -- >8 -- Subject: [PATCH] testsuite: Cut down 27_io/basic_istream/.../94749.cc for simulators The test wchar_t/94749.cc can take about 10 minutes on some simulator/host combinations with char/94749.cc at a third of that time. The cause is test05 which is quite heavy and includes wrapping a 32-bit counter. Run it only for native setups. * testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc (main) [! SIMULATOR_TEST]: Also exclude running test05. * testsuite/27_io/basic_istream/ignore/char/94749.cc: Ditto. --- libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc | 2 +- .../testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc index 6416863983b7..9160995c05ec 100644 --- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc @@ -221,8 +221,8 @@ main() test02(); test03(); test04(); - test05(); #ifndef SIMULATOR_TEST + test05(); test06(); #endif } diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc index 65e0a326c109..a5b9eb71a389 100644 --- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc @@ -221,8 +221,8 @@ main() test02(); test03(); test04(); - test05(); #ifndef SIMULATOR_TEST + test05(); test06(); #endif } -- 2.30.2