Initial startup can take a long time (+20s) due to the "Downloads" find routine.

Bug #1117840 reported by Tobin Davis
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Image Writer
Fix Released
Medium
Tobin Davis

Bug Description

V0.7.

Some people report longer startup times for v0.7. This is due to a new function at startup to set the default working directory to "Downloads", which can vary locations in each version of WIndows. Need to profile this code and optimize it.

Tags: v0.7
Revision history for this message
Roland Rüdenauer (roland-ruedenauer) wrote :

Image Writer searches almost any subdirectory of my home directory for the Downloads folder. Sure, this may take some time.
The search should be restricted to only immediate subdirectories by replacting QDirIterator::Subdirectories with QDirIterator::NoIteratorFlags.

Even better would be using the SHGetKnownFolderPath API call:

PWSTR pPath = NULL;
if (SUCCEEDED( SHGetKnownFolderPath( FOLDERID_Downloads, KF_FLAG_NO_ALIAS, 0, &pPath)) )
{
    myHomeDir = QString::fromWCharArray( pPath );
    CoTaskMemFree( pPath );
}

Revision history for this message
Tobin Davis (gruemaster) wrote : Re: [Bug 1117840] Re: Initial startup can take a long time (+20s) due to the "Downloads" find routine.

On Fri, 2013-02-15 at 02:06 +0000, Roland Rüdenauer wrote:
> Image Writer searches almost any subdirectory of my home directory for the Downloads folder. Sure, this may take some time.
> The search should be restricted to only immediate subdirectories by replacting QDirIterator::Subdirectories with QDirIterator::NoIteratorFlags.
Not sure if this will work on XP or future versions of Windows.
XP: c:\Documents and Settings\<user>\My Documents\Downloads <-- two
layers deep here.
Win7: c:\users\<userid>\Downloads <--Works here.
Win8: Same.

I don't have a copy of vista off hand.
From http://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%
28v=vs.85%29.aspx
Minimum supported client
 Windows Vista

So again, won't support XP.

I will revisit this probably mid summer. Right now, XP still holds ~20%
of the install base (according to some of my statistic searches).

I could hard code it, but I hate hard coded paths in compiled code. I
have other solutions I will be looking into though, and I hope to
address this in the next month.

--
--

Tobin Davis

A formal parsing algorithm should not always be used.
  -- D. Gries

Revision history for this message
Jeff B (skydiver38) wrote :

We can do some shortcutting by using QSysInfo (http://doc.qt.digia.com/4.6/qsysinfo.html#WinVersion-enum) and then looking for a directory that *should* exist, following it up with a search if the expected dir wasn't found.

That way, we have a fallback, but don't go on some convoluted search if it isn't necessary....

Even if we don't use QSysInfo, we can have a list of "known locations" that we search for first, again falling back to a more extensive search if nothing is found.

Changed in win32-image-writer:
status: Confirmed → Fix Committed
assignee: Tobin Davis (gruemaster) → Giuseppe Cantone (cantone-g1955)
status: Fix Committed → Confirmed
Tobin Davis (gruemaster)
Changed in win32-image-writer:
assignee: Giuseppe Cantone (cantone-g1955) → Tobin Davis (gruemaster)
Tobin Davis (gruemaster)
Changed in win32-image-writer:
status: Confirmed → Fix Committed
Tobin Davis (gruemaster)
Changed in win32-image-writer:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.