-
Notifications
You must be signed in to change notification settings - Fork 192
Closed
Labels
available on masterFix is done on master branch, issue closed on next releaseFix is done on master branch, issue closed on next releaseenhancementNew feature or requestNew feature or request
Milestone
Description
Describe the bug
The path::parent_path()
method is unreasonably slow compared to something like POSIX's dirname(3)
.
To Reproduce
Using this file:
#include <libgen.h>
#include <chrono>
#include "ghc/filesystem.hpp"
int main(int argc, char *argv[])
{
{
std::string path_str = "/a/really/long/path/to/test/performance/of/parent_path";
{
ghc::filesystem::path path(path_str);
auto start = std::chrono::system_clock::now();
for (int lpc = 0; lpc < 1000000; lpc++) {
auto par = path.parent_path();
}
auto stop = std::chrono::system_clock::now();
printf("ghc duration: %d\n", (int32_t) (stop - start).count());
}
{
auto start = std::chrono::system_clock::now();
for (int lpc = 0; lpc < 1000000; lpc++) {
auto par = (char *) malloc(path_str.length() + 1);
strcpy(par, path_str.c_str());
dirname(par);
free(par);
}
auto stop = std::chrono::system_clock::now();
printf("dirname(3) duration: %d\n", (int32_t) (stop - start).count());
}
}
}
Compiled with:
$ g++ --std=c++14 -O3 path_perf.cc
On my 2013 iMac with a 3.5Ghz Core i7, I get the following results:
ghc duration: 2337478
dirname(3) duration: 94162
Expected behavior
The performance of parent_path()
should be a lot better.
Additional context
I'm using this library in https://github.com/tstack/lnav and parent_path()
turned out to be a major source of slowness when a lot of files were open.
(This library is great, thanks for making it!)
Metadata
Metadata
Assignees
Labels
available on masterFix is done on master branch, issue closed on next releaseFix is done on master branch, issue closed on next releaseenhancementNew feature or requestNew feature or request