[jira] [Issue Comment Edited] (PIVOT-656) FileBrowserSheet seems frozen while browsing network folders

["Volker Seibt (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PIVOT-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160903#comment-13160903 ] 

Volker Seibt edited comment on PIVOT-656 at 12/1/11 1:22 PM:
-------------------------------------------------------------

I'm in luck to have access to slow network drives ;-), so I was able to profile the issue.

There are actualy two spots:
1.  The file system roots are read to often. On slow (network-)drives it can take a second per drive to answer.
2. The HIDDEN_FILE_FILTER is used to early. On slow drives checking the hidden-flag takes to long per file.

I will add a patch (on 2.0 release tag) to address this issues. With the patch:
1. File system roots are only read once. For reread you have to close the sheet. This can be improved by adding a refresh button, but for the first time it's the easiest solution.
2. The HIDDEN_FILE_FILTER is moved from "list_files()" to the "queueCallback" in the same method. It's not realy faster, but for the user it seems faster because the first file is shown much faster. Functionality is kept.

In my network environment this patch changes the experience from "nearly not usable" to "ok".
                
      was (Author: vseibt):
    I'm in luck to have access to slow network drives ;-), so I was able to profile the issue.

There are actualy two spots:
#  The file system roots are read to often. On slow (network-)drives it can take a second per drive to answer.
# The HIDDEN_FILE_FILTER is used to early. On slow drives checking the hidden-flag takes to long per file.

I will add a patch (on 2.0 release tag) to address this issues. With the patch:
# File system roots are only read once. For reread you have to close the sheet. This can be improved by adding a refresh button, but for the first time it's the easiest solution.
# The HIDDEN_FILE_FILTER is moved from {{list_files()}} to the {{queueCallback}} in the same method. It's not realy faster, but for the user it seems faster because the first file is shown much faster. Functionality is kept.

In my network environment this patch changes the experience from "nearly not usable" to "ok".
                  
> FileBrowserSheet seems frozen while browsing network folders
> ------------------------------------------------------------
>
>                 Key: PIVOT-656
>                 URL: https://issues.apache.org/jira/browse/PIVOT-656
>             Project: Pivot
>          Issue Type: Improvement
>    Affects Versions: 1.5.1
>            Reporter: A.J.
>             Fix For: 2.1
>
>         Attachments: apache-pivot-terra-fileBrowserSkin-performance.patch
>
>
> Our customer complains about the FileBrowserSheet being unresponsive while browsing network folders.
> I haven't been able to reproduce this in my development environment but I saw this in 'action' (or inaction in this case).
> They click a folder then ... nothing happens, they wait, then wait. They are free to try other folders (I guess this is asynchronous task) but nothing happens.
> I've asked them to navigate the same network path with the Windows explorer which has no apparent problem (some slowdowns at worst).
> So, it's hard to say where the problems is (no stack trace) but there is a problem.
> One first improvement that could be done would be to display an hourglass (busy cursor) while the current I/O operation is pending.
> Another one could be also to set a timer after which the I/O operation would be canceled (or abandonned) and give back hand to the calling code.
> That's all I'm thinking fo r now.
> As soon as I can get some more info on the origin of the problem, I'll update this issue.
> Cheers, 
> A.J.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira