|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-07 13:06:59
At 11:12 AM 1/5/2003, Daniel Yerushalmi wrote:
>Hi All
>
>I have code that iterate on directory tree (the recursive function)
>addFolder. I had profiled it (MSVC 6.5)
> Func Func+Child Hit
> Time % Time % Count Function
>---------------------------------------------------------
> 28.780 43.2 31.818 47.8 567
>boost::filesystem::is_directory(class boost::filesystem::path const &)
>(operations_posix_windows.obj)
> 10.136 15.2 22.666 34.0 151
>boost::filesystem::directory_iterator::directory_iterator(class
>boost::filesystem::path const &) (operations_posix_windows.obj)
> 7.249 10.9 7.249 10.9 592 `anonymous
>namespace'::find_next_file(void *,class boost::filesystem::path const
>&,struct _WIN32_FIND_DATAA &) (operations_posix_windows.obj)
>(operations_posix_windows.obj)
>
>As you can see most of the time is spent in the is_directory function. I
>know that (in Win32 - ::FindNextFileA at least) the information for
>"is_directory" can be fetched in the "::find_next_file". I suggest to add
>m_is_directory attribute to the path class (initial value "unknown") and
>have is_directory read from this attribute if possible. (For my
application
>the is_directory time is swamped by other things but for other directory
>iterating applications this may be significant)
Before answering the question "How can we cache file attributes between
calls to filesystem function?" we need to answer the question "Should we
cache file attributes between filesystem functions?"
The problem is race-conditions. "c:/foo/bar" may have been a directory the
last time we saw it, but now is a file. I'd want to think about that a bit
more before doing any caching.
I'd like the filesystem library to mature and see wider use before worrying
about optimizations, too.
Thanks for the profiling,
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk