So, Piotr, is what is in SVN now good (after Sandro's big patch)?
~Roger
Sent from my iPhone
On May 15, 2012, at 7:25 AM, Sandro Martini <[email protected]>
wrote:
Hi Piotr,
I don't think this would help. If a thread iterates over a
collection while another thread is modifying it, you'd get
ConcurrentModificationException anyway.
Just to be sure of this ... the code returns a new Iterator so we
should be ok.
public Iterator<URL> iterator() {
return new Iterator<URL>() {
private Iterator<URI> iterator =
resourceCache.iterator();
...
Some info on Iterators and multithread even here (just for reference):
http://www.oodesign.com/iterator-pattern.html
Is this iterator ever used somewhere? If it is, we have to solve it
somehow differently. Nevertheless making just puts and gets
synchronized solved the issue at least for us - we don't encounter
any crashes while starting the app.
Ok, so I think all should be good ...
The scenario that was causing this was the following:
Thread one: load window 1 from BXML
Thread two: load window 2 from BXML
Thread three: load window 3 from BXML
Thread four: load window 4 from BXML
Join threads
In GUI thread - open all the loaded windows
This could be a very interesting new Tutorial / Sample, if you have
some time it would be great to prototype something.
Or if someone of us has some time ... if possible I'll try in next
days, but if you have something ready to use please tell me.
It is important for us to make it work (stable), because on a
multicore machine it improves loading windows by about 40% (not
perfect, but visibly faster).
Yes, I understand, and it's a major problem in all modern software ...
better usage of multicores ... and it's one of the reasons why I like
so much Scala :-) .
BTW: Have you ever optimised pivot for faster startup times? The
first thing we noticed when we switched from Swing is that Pivot
was somehow slower to start up. This is worrying me - now it is not
a problem it the user waits for 1 second to load the app (I'm
talking about warm start up), but if in future the gui gets bigger...
No, I don't think none of us has even done something like this ... an
in-depth look with a Profiler would be welcome (mabye even starting
with the NetBeans profiler, and/or VisualVM). An issue for 2.1 on this
could be add.
The competition using JavaScript doesn't have that problem. :
( Maybe there are some possibilities to limit the amount of
classloading or make some things more lazy?
Yes, I know ... maybe for 2.1 we could really try to do something, but
before someone of us should do some analysis with a profiler, to
better understand if/where we can improve ...
Bye,
Sandro
