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

             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: link
Be 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).