[
https://issues.jboss.org/browse/JBIDE-20362?page=com.atlassian.jira.plugi...
]
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)