https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044
Bug ID: 71044
Summary: Optimize std::filesystem implementation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Before the code is moved from std::experimental::filesystem to std::filesystem
(and into the shared library) there are a few improvements that should be made.
http://wg21.link/lwg2674 relaxes requirements on path::iterator so that a path
is no longer required to embed a container of paths. The components could be
stored as string_view objects, and only converted to path objects as needed
(generally that means when a path::iterator is dereferenced).
Parsing and splitting a path into components could be done lazily, so that it
isn't done for intermediate temporary copies of a path, only the final value
that is manipulated. Move semantics might mean this is unnecessary, since
performance-sensitive code can usually move values instead of copying them.
Directory iterators currently construct a path object on every increment. This
means that incrementing a directory iterator five times then dereferencing it
constructs five paths which are never used (and each one is eagerly split into
components, allocating a container of paths!). Construction of the path could
be postponed so that it's only done on dereference, so that the five increments
are cheap. This has thread-safety consequences, as the dereference is a const
operation and could be performed concurrently, so the lazy construction of the
path needs to be synchronized.
