GetCaseCorrectPathName is a slow and likely obsolete function, mostly removed from the code. Removing temporarily its last occurance (by the following test patch) resulted ~10% speed up in LO starting time on Windows. So it would be fine to remove (or replace it GetLongPathName or something relevant, if needed) finally. --- a/sal/osl/w32/file_dirvol.cxx +++ b/sal/osl/w32/file_dirvol.cxx @@ -1666,7 +1666,7 @@ oslFileError SAL_CALL osl_getFileStatus( if ( uFieldMask & osl_FileStatus_Mask_FileURL ) { - if ( !pItemImpl->bFullPathNormalized ) + if ( 0 && !pItemImpl->bFullPathNormalized ) { ::osl::LongPathBuffer< sal_Unicode > aBuffer( MAX_LONG_PATH ); sal_uInt32 nNewLen = GetCaseCorrectPathName( rtl_uString_getStr( pItemImpl->m_pFullPath ), Some information in sal/osl/w32/file_url.cxx: // Same as GetLongPathName but also 95/NT4 static DWORD GetCaseCorrectPathNameEx( LPWSTR lpszPath, // path buffer to convert DWORD cchBuffer, // size of path buffer DWORD nSkipLevels, BOOL bCheckExistence )
Thanks for the solution, but please follow our guidelines for submitting patches: https://wiki.documentfoundation.org/Development/GetInvolved We use gerrit to review and apply patches.
Jan - this is an easy-hack; the patch is just to highlight the win possible from optimizing the implementation here =) This is fundamentally a cleanup to use a built-in windows function instead of a hacked-up compatibility implementation.
Hi, I am working on this bug.
Created attachment 132121 [details] Patch for resolving the Bug
Thanks for the patch ! =) a few comments: * can you submit it to gerrit ? - it takes a bit of setup - but good to get that done. * can you remove the dead code rather than commenting it out ? if we had every line of code we'd removed over time still in the source - we would have 50x as much code and it would be un-readable & un-grep-able =) Otherwise - this looks good; can you test your binaries on Windows XP ? and ensure that this method is triggered & continues to work ? I hope you can just copy your 'instdir' across and run it there. Thanks !
Created attachment 132143 [details] Patch for resolving the Bug
A polite ping, still working on this patch?
No reason to be in NEEDINFO state if you ask me.
i Want to solve this bug as my first easy hack . i want to confirm whether i should simply remove all pieces of code where i find the function GetCaseCorrectPathName() called, or something more? .Thank you for your help in advance :)
(In reply to Archit Jugran from comment #9) > i Want to solve this bug as my first easy hack . i want to confirm whether i > should simply remove all pieces of code where i find the function > GetCaseCorrectPathName() called, or something more? .Thank you for your help > in advance :) Putting it back to NEW! @Michael Meeks, Could you please help Archit Jugran here?
The "hack" to be done here is so trivial (especially when there already is a patch attached (that was ignored)), that any help would essentially mean doing the hack for him/her.
Although the patch is there in the comments,written by someone else, but it has not been committed yet. I want to seek the permission to look into it for possible changes and correction if any error arises.
Please do re-do the work yourself, and submit it to gerrit for testing if Archit cannot do this =) Thanks !
A polite ping, still working on this bug?
Sorry for the delay , I am still working on it.
Clearly life means more to him/her than fixing this bug (and I don't deny it) (what am I talking about? check the email address of the assignee), reassigning to default.
See comment 11. For this "easy hack" to have any relevance at all any longer as an indication of hacking skills, I'd say that the easy-hacker is expected to do some measurements, too, to indicate how much a win doing it gives us...
This "easy hack" is not that easy. Anyone who would attempt to fix this, should not expect one's task to be limited to replacement of uses of the function with its Win32 counterpart API. These two actually have differences in behaviour, and we in fact depend on the specifics of GetCaseCorrectPathName (which makes the brute-force attempts replacing one with the other to fail in unit tests). The debugging of the unit tests failure cause, understanding the differences, documenting them (here), and investigating if dependencies on those differences might be fixed in the code is the minimum to hack on this.
I am trying to work on this https://gerrit.libreoffice.org/c/core/+/130144
(In reply to Kunal Pawar from comment #29) > I am trying to work on this > https://gerrit.libreoffice.org/c/core/+/130144 Hello Kunal, thanks for taking this one! Since you are working on it, please set the Assignee field (at the top) to your email address, and set the status to ASSIGNED. This helps us with bug triage.
Kunal Pawar committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/92e835dbf00590c9c29509d2995cc7918a9bbb90 tdf#98705 Replace GetCaseCorrectPathName with GetLongPathNameW It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks like this can be closed