[jbosstools-issues] [JBoss JIRA] (JBIDE-20362) Extracting of a download runtime is slow on Mac

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-20362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281045#comment-13281045 ] 

Rob Stryker commented on JBIDE-20362:
-------------------------------------

[~mmalina] Ok... I'm, not gonna say "you're crazy!", even if I'm thinking it... ... but If you look at my changes, they are 100% UI only. I think it's extremely unlikely (almost unthinkable really) that changes to our UI is what's causing this. 

But let's think about this. What could possibly be causing your download speed to slow down? 

1) Is the label reporting 2.3mb/s? or is the label reporting 20mb but behaving as if it's 2.3mb/s?  
2) If the label is REPORTING 2.3mb/sec,  then it means the actual download speed is 2.3mb/sec and it's not just a slow UI that's having trouble updating. If the label is listing it as 20mb but it's just slow, then that's a UI issue clearly. 
3) Progress monitor work is almost always done asynchronously... at least when it comes to UI, and the UI is by far the slowest part.   Question is, is it done asynchronously so it's not blocking the actual download?  I'll need to check, but I can't see how it would be. 

Tests:
  With patch:    new server wizard:  consistant 6mb/s...  preference page:  also 6mb/s  -   3 attempts each
   Without patch:  new server wizard:  consistant 6mb/s...  preference page:  also 6mb/s  -   3 attempts each


Basically, what's changed here is that we still update the progress monitor in 100% exactly the same way as before, we've just changed which root progress monitor is being used. The root progress monitor being used now will only fire Display.asynch swt updates less frequently. I believe there is another layer of progress monitor delegation,  but this happens all the time any time someone makes a subprogress monitor or a wrapped progress monitor, which happens seriously all the time.  So one extra layer of progress monitor passing shouldn't affect download speed at all, especially not on the order of 90% speed drop.  It's almost unheard of. 

[~fbricon] Can you test this patch?  It'd be really helpful to get another data point. I'm not noticing any slowdown. 


> Extracting of a download runtime is slow on Mac
> -----------------------------------------------
>
>                 Key: JBIDE-20362
>                 URL: https://issues.jboss.org/browse/JBIDE-20362
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: runtime-detection
>    Affects Versions: 4.3.0.Beta2
>            Reporter: Martin Malina
>            Assignee: Rob Stryker
>             Fix For: 4.4.1.Final
>
>
> While playing with the Download runtime fuctionality, I noticed that once a runtime (e.g. EAP 6.2) is downloaded, the extraction takes very long. I think it used to be fast and the extraction was done without any progress reporting. But now it seems that every subdirectory in the archive is being printed out which slows it down.
> This extraction process took 1 min 23 sec for EAP 6.2 and I have an SSD. On a command line, this would take a few seconds.
> I think the solution may be to simply show "Extracting" without printing out each file/directory that is being extracted.
> (Furthermore, the progress bar does not reflect the progress - it seems there is still only perhaps 5 % done and then it's suddenly over.)
> I can record a screencast if you like, but I think this should be easy to replicate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)