Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tinydir_open_sorted is really slow under windows #6

Closed
jpjodoin opened this issue Jan 15, 2014 · 4 comments
Closed

tinydir_open_sorted is really slow under windows #6

jpjodoin opened this issue Jan 15, 2014 · 4 comments

Comments

@jpjodoin
Copy link

I have a folder of 8000 images in it. If I call tinydir_open_sorted on it's path, it will take as long as 2 minutes to retrieve the full list of file. I am under MSVC 2010 under windows 7 x64. Profiling shows 99.9% of the time spent in an unknown method. If I use tinydir_open instead and I sort the file myself using a vector and std::sort, the result will take much less than a second to return.

I think the problem is with the use of realloc, that must constantly allocate new block of memory compare to a std::vector that might handle the reallocation much better.

Here's the C++ version that run much faster (to compare with tinydir_open_sorted)
std::vectorstd::string dirList
tinydir_open(&dir, dirPath.c_str());
while (dir.has_next)
{
tinydir_file file;
tinydir_readfile(&dir, &file);
if(!file.is_dir)
dirList.push_back(std::string(file.name));
tinydir_next(&dir);
}

tinydir_close(&dir);
std::sort(dirList.begin(), dirList.end());
return dirList;

@jpjodoin
Copy link
Author

I think a good solution would be to count the number of file before and calling the allocation one time instead.

@cxong
Copy link
Owner

cxong commented Jan 15, 2014

Yes you are right the realloc is the most likely culprit. The current implementation is very inefficient as it reallocs every time the size grows. I think simply changing to a doubling of capacity will make it fast enough.

@jpjodoin
Copy link
Author

Yeah. That would most likely be a good enough improvement.

@cxong cxong closed this as completed in 7db6629 Jan 16, 2014
@cxong
Copy link
Owner

cxong commented Jan 16, 2014

I've decided to count the number of files beforehand; I tested on a folder with 10000 subfolders and this seemed the fastest:

Times in seconds
Previous: 78.579
Doubling realloc: 0.04
Counting: 0.019

Thanks for raising this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants