Take advantage of some newer optimizations of FindFirstFile.
This sets the "large buffer" flag for file finding which is supposed increase throughput at potentially increased latency. Since we seldom interrupt find operations and don't block the UI thread, this should improve performance slightly.
This also sets the "basic information" flag which will omit the short filename, which the documentation says should make it a bit faster. I checked and there is currently no user of this data.
See also:
http://blogs.msdn.com/b/oldnewthing/archive/2013/10/24/10459773.aspx
BUG=
Review URL: https://codereview.chromium.org/48183005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@231490 0039d316-1c4b-4281-b951-d872f2087c98
CrOS-Libchrome-Original-Commit: 3896febbee0f1137723978ffb01534020dfd9672
diff --git a/base/files/file_enumerator.h b/base/files/file_enumerator.h
index ce9bd1f..38bb833 100644
--- a/base/files/file_enumerator.h
+++ b/base/files/file_enumerator.h
@@ -53,6 +53,9 @@
Time GetLastModifiedTime() const;
#if defined(OS_WIN)
+ // Note that the cAlternateFileName (used to hold the "short" 8.3 name)
+ // of the WIN32_FIND_DATA will be empty. Since we don't use short file
+ // names, we tell Windows to omit it which speeds up the query slightly.
const WIN32_FIND_DATA& find_data() const { return find_data_; }
#elif defined(OS_POSIX)
const struct stat& stat() const { return stat_; }