public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dartdart26 at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/101923] New: std::function's move ctor is slower than the copy one for empty source objects Date: Sun, 15 Aug 2021 13:17:25 +0000 [thread overview] Message-ID: <bug-101923-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101923 Bug ID: 101923 Summary: std::function's move ctor is slower than the copy one for empty source objects Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dartdart26 at gmail dot com Target Milestone: --- std::function's move constructor calls swap() irrespective of whether the source object is empty or not. In contrast, the copy constructor first checks if the source object is empty and if it is, nothing is being done as the `this` object is constructed in an empty state by _Function_base(). Calling swap() on an empty source requires more work, because some data needs to be copied - for example, the POD data cannot be moved. Could the move constructor check if the source is empty too, as the copy one does? Please let me know if I am missing a rule that prevents that. I have noticed that on version 9.3.0, but I see the code is the same in current master at: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/std_function.h;hb=c22bcfd2f7dc9bb5ad394720f4a612327dc898ba#l391 I have tested on a MacBook M1 and the copy ctor for empty sources is almost 2x faster than the move ctor: ----------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------- copy 0.945 ns 0.945 ns 555789159 move 1.83 ns 1.83 ns 382183169 I have made an YouTube video for describing my findings and the benchmark results: https://www.youtube.com/watch?v=WA3mKab-tn8
next reply other threads:[~2021-08-15 13:17 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-15 13:17 dartdart26 at gmail dot com [this message] 2021-08-15 13:38 ` [Bug libstdc++/101923] " dartdart26 at gmail dot com 2021-08-15 17:54 ` nok.raven at gmail dot com 2021-08-16 7:18 ` dartdart26 at gmail dot com 2021-08-16 7:30 ` [Bug tree-optimization/101923] " pinskia at gcc dot gnu.org 2021-08-17 6:09 ` dartdart26 at gmail dot com 2021-08-17 10:00 ` redi at gcc dot gnu.org 2021-08-17 10:25 ` redi at gcc dot gnu.org 2021-08-17 13:24 ` cvs-commit at gcc dot gnu.org 2021-08-18 6:02 ` dartdart26 at gmail dot com 2021-10-12 10:59 ` cvs-commit at gcc dot gnu.org 2022-12-29 22:14 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-101923-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).