/u/130188/crop6202f586c08b3.png?f=community)
Lux.Architectuur | Van Dromen tot Wonen | www.Lux-a.nl
:strip_icc():strip_exif()/u/6988/greg.jpg?f=community)
Nee, want je voert dit nu uit in de main thread. De GUI zal dus pas worden ververst als dit klaar is, aangezien het dan pas de kans krijgt om dit te doen.
Dit zal je dus in aparte worker threads moeten doen. Zoek maar eens op de term swingworkers etc.
Dit zal je dus in aparte worker threads moeten doen. Zoek maar eens op de term swingworkers etc.
Neem je whisky mee, is het te weinig... *zucht*
/u/319882/crop594f9e2133708_cropped.png?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Nadeel met normale runnables is wel dat je ze zelf in een thread moet uitvoeren of ergens zelf een threadpool moet managen.
Met de Swingworkers is dat allemaal al voor je afgehandeld en wordt de thread in de workers executor service gegooid.
Maar dan evengoed nog wel in een aparte thread anders blokkeert de gui alsnog tot dit klaar is.
Met de Swingworkers is dat allemaal al voor je afgehandeld en wordt de thread in de workers executor service gegooid.
Ligt er maar net aan of je de updates in de gui direct wilt zien natuurlijk. In dit simpele voorbeeld lijkt me jouw voorstel (processen, verzamelen, gui updaten) ook beter omdat dat gewoon vele malen sneller is
Maar dan evengoed nog wel in een aparte thread anders blokkeert de gui alsnog tot dit klaar is.
[ Voor 58% gewijzigd door momania op 05-10-2009 18:02 ]
Neem je whisky mee, is het te weinig... *zucht*
Het is gewoon dat ik niet weet of 't zich loont om 't in een aparte thread te gooien. Ik heb even in C# gebenched met wat C# en windows specifieke (\n -> \r\n) aanpassingen::
Ligt er maar net aan of je de updates in de gui direct wilt zien natuurlijk. In dit simpele voorbeeld lijkt me jouw voorstel (processen, verzamelen, gui updaten) ook beter omdat dat gewoon vele malen sneller is
Maar dan evengoed nog wel in een aparte thread anders blokkeert de gui alsnog tot dit klaar is.
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| using System; using System.Text; using System.Windows.Forms; namespace WindowsFormsApplication1 { public partial class Form1 : Form { public Form1() { InitializeComponent(); DateTime s = DateTime.Now; StringBuilder sb = new StringBuilder(); for (int i = 1; i < 99999; i++) sb.AppendLine(i.ToString()); textBox1.Text = sb.ToString(); Console.WriteLine(DateTime.Now - s); s = DateTime.Now; for (int i = 1; i < 99999; i++) textBox2.Text += i.ToString() + "\r\n"; Console.WriteLine(DateTime.Now - s); } } } |
Zoals je ziet zoveel mogelijk equivalent gehouden met de code uit TS.
Output:
00:00:00.0290016 00:01:07.2508466
Een slordige 2300 keer zo snel
Vandaar dat ik 't gedoe met aparte threads niet helemaal zie. Maar again; dit is C#, ik weet niet wat deze bench in Java zou doen. Als mijn GUI 0.02 seconden blokkeert... tjah. Boeie
[ Voor 4% gewijzigd door RobIII op 05-10-2009 18:20 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
:strip_icc():strip_exif()/u/172182/crop5ea83ce62d327.jpeg?f=community)
Eensch als je de updates tussendoor wil zien, maar a) zie ik er het nut niet van en b) haal ik dat nergens expliciet uit wat de TS zegt her-of-der.
Daar haal ik uit dat 't 4 seconden niets is en dan alles in 1 keer (wat overigens nog gunstig is in zijn geval, anders had een een crapload langer geduurd
) maar nergens dat 'ie het per-se 1 voor 1 wil zien verschijnen. Wel lees ik uit z'n laatste zin dat 'ie verwacht dat de GUI onderwijl bijgewerkt wordt (en wellicht verwacht TS ook dat 'ie daarmee dus nog gewoon z'n GUI zou moeten/willen/kunnen gebruiken). En again; ik zie er dan het nut niet van als TS de updates wél per-se zou willen zien.
[ Voor 52% gewijzigd door RobIII op 05-10-2009 18:27 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Toch moet je het in java in een aparte thread doen, ook al wil je je resultaat in 1 keer zien. Punt is nml. dat de default thread waarin je code uitvoert de main thread is en je dus elke andere gui update blokkeert.
Het mooiste blijft dan nog om het in Swingworkers te doen. De 'doInBackground' voert je code dan uit in een aparte threadpool. Wil je daarna gui updates doen, stop je die code in de 'done' methode en dat wordt dan weer in een andere aparte threadpool uitgevoerd. Zo zullen je gui updates iig niet ge-queued/vertraagd worden door background processen die (nog) niets met de gui te maken hebben
offtopic:
En heb je geen thread-safety nodig, dan is de StringBuilder (vanaf jdk 5) nog sneller
En heb je geen thread-safety nodig, dan is de StringBuilder (vanaf jdk 5) nog sneller
[ Voor 42% gewijzigd door momania op 05-10-2009 19:08 ]
Neem je whisky mee, is het te weinig... *zucht*
Ik denk dat het niet gunstig is in zijn geval. Het is te vergelijken met elk besturingssysteem. Als je alles in dezelfde thread zou doen dan zou bijvoorbeeld Windows moeten kiezen tussen het afspelen van geluid of het weergeven van je afspeelprogramma. Door middel van Threads kun je dit elkaar zo snel af laten wisselen dat je het idee krijgt dat het gelijk gaat. Natuurlijk is sinds de multi core processoren dit vanzelfsprekend mogelijk. Maar er lopen behoorlijk wat Threads op je pc door elkaar heen. Zie je proceslijst in Windows taskmanager maar ook binnen die processen en binnen programmas moet dat kunnen.:
[...]
Eensch als je de updates tussendoor wil zien, maar a) zie ik er het nut niet van en b) haal ik dat nergens expliciet uit wat de TS zegt her-of-der.
[...]
Daar haal ik uit dat 't 4 seconden niets is en dan alles in 1 keer (wat overigens nog gunstig is in zijn geval, anders had een een crapload langer geduurd
Wat? Een "freeze" van de GUI voor 0.02 seconden? Want de rest van 't systeem lijdt er niet (echt) onder als 't goed is (en zeker niet als 't maar 0.02 seconden is; het is natuurlijk andere koek als je die gein 60x per seconde gaat uitvoeren waarbij je telkens 0.02 sec. nodig hebt)
Euh; ik weet wat threads zijn en dat er meer dan 1 proces tegelijkertijd op je systeem actief is dankjewel
(Er is overigens een verschil in multitasking wat jij beschrijft en multithreading ). Ik heb 't over 't feit dat ik (vanuit C# oogpunt gezien) 't onzin vind om een aparte thread te lanceren voor 't vullen van een textbox als dit a) "eenmalig" gebeurt, b) een "gui freeze" van 'maar' 0.02 seconden oplevert. Maar als dit onder Java gebruikelijk is dan leef je uit Als 't nou een merkbare/storende 'GUI freeze' zou opleveren dan was, zoals ik 't zie, een aparte thread nog te verdedigen, maar in dit geval lijkt het me gewoon zonde van devtijd. Mind you dat ik die bench niet onder Java heb uitgevoerd en dat 't in dat geval dus best wel eens verdedigbaar zou kunnen zijn als mijn "StringBuilder idee" niet acceptabel snel genoeg zou zijn.
[ Voor 15% gewijzigd door RobIII op 06-10-2009 01:46 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
For the record::
[...]
Zoals je ziet zoveel mogelijk equivalent gehouden met de code uit TS.
Output:
00:00:00.0290016 00:01:07.2508466
Een slordige 2300 keer zo snel
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| String lineSeparator = "\r\n"; JTextArea area = new JTextArea(); StringBuilder builder = new StringBuilder(); long start = System.currentTimeMillis(); for (int i=0; i<99999; i++) { builder.append(i).append(lineSeparator); } area.setText(builder.toString()); System.out.println("builder: "+ (System.currentTimeMillis() - start) + "ms"); start = System.currentTimeMillis(); for (int i=0; i<99999; i++) { area.append(String.valueOf(i)); area.append(lineSeparator); } System.out.println("textarea: "+ (System.currentTimeMillis() - start) + "ms"); |
Output:
builder: 313ms textarea: 1187ms
Wist niet dat textboxen in C# zo sloom zijn
Neem je whisky mee, is het te weinig... *zucht*
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
Of Stringbuilders in Java zo sloom:
[...]
Output:
builder: 313ms textarea: 1187ms
Wist niet dat textboxen in C# zo sloom zijn
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Zonder de line separator, die Rob vergeten is, is het al iets sneller: 78ms:
[...]
Of Stringbuilders in Java zo sloom
Neem je whisky mee, is het te weinig... *zucht*
Rob doet ook een AppendLine, dus een line seperator is niet nodig:
[...]
Zonder de line separator, die Rob vergeten is, is het al iets sneller: 78ms
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
:strip_icc():strip_exif()/u/126096/crop580e4f8566fec_cropped.jpeg?f=community)
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Nope, die crossthread exceptions (ofwel: concurrent modification exceptions) krijg je niet als je de swingworkers correct gebruikt.
De swingworker heeft 2 core methodes die je kan overriden: 'doInBackground()' en 'done()'
'doInBackground()' Wordt uitgevoerd in een managed threadpool en dat is dus de plek om je zware werk te offloaden.
Wil je gui updates doen nadat je werk klaar is, dan doe je dat via de 'done()' methode. Deze wordt uitgevoerd op de normale event dispatch thread en komt dus netjes in een queue van gui updates.
Wil je toch tijdens een background task tussendoor je gui updaten, doe je dat via 'SwingUtilities.invokeLater(Runnable doRun)'
Dat is de manier om direct iets op de event dispatcher te queuen.
Nogmaals: standaard code uitvoer in swing wordt altijd op de event dispatch thread uitgevoerd en blokkeert dus alle gui updates tot de code klaar is. (totale blokkade dus)
[ Voor 7% gewijzigd door momania op 06-10-2009 11:04 ]
Neem je whisky mee, is het te weinig... *zucht*
:strip_icc():strip_exif()/u/172554/avatar60px.jpg?f=community){kind=avatar}
ik zit een beetje met hetzelfde probleem. Dit is wat ik tot nu toe te weten ben gekomen is dit:
Je wilt het appenden op een jtextarea maar 1x doen!!! een jTextArea is enorm traag!
Dit is wat je het beste kan doen:
Bovenstaande code gaat waanzinnig snel. Als je iedere keer een append doet op je TextArea dan is hij enorm traag. Je String moet namelijk telkens opniew opgebouwd worden. En elke string die je toevoegd word steeds trager. Ik zit hier dus met zo'n 600-duizend tot 10 miljoen regels. Het tekenen in de jTextArea duurt langer als het creeren van de StringBuffer.
Het open van een tekstfile van 100MB en vervolgens wegschrijven in het panel duurt zo'n 15 seconden. Het telkens appenden van een string op een jTextArea bij een tekstfile van 10MB duurt een slordige 2 minuten.
Het probleem waar ik dus tegenaan loop is dat mijn GUI dus mooi een tijdje blijft hangen. (Net zoals Notepad)
Wellicht dat ik het zo laat. (Openen van de 100MB tekstfile duurt in notepad zo'n 40 seconden
)
Edit: Als je de StringBuffer een begingrootte heeft kun je nog wat extra performance eruit persen. Ofwel:
StringBuffer sb = new StringBuffer(18000000); //array van 18000000 tekens
Een StringBuilder is in veel gevallen trager als een StringBuffer heb ik gemerkt.
Ook moet je dit niet doen:
Dat is ook enorm traag.
Je wilt het appenden op een jtextarea maar 1x doen!!! een jTextArea is enorm traag!
Dit is wat je het beste kan doen:
Java:
1
2
3
4
5
6
| StringBuffer sb = new StringBuffer(); for(int i = 1; i < 99999; i++) { sb.append(i+ "\n"); } jTextArea1.append(sb.toString()); |
Bovenstaande code gaat waanzinnig snel. Als je iedere keer een append doet op je TextArea dan is hij enorm traag. Je String moet namelijk telkens opniew opgebouwd worden. En elke string die je toevoegd word steeds trager. Ik zit hier dus met zo'n 600-duizend tot 10 miljoen regels. Het tekenen in de jTextArea duurt langer als het creeren van de StringBuffer.
Het open van een tekstfile van 100MB en vervolgens wegschrijven in het panel duurt zo'n 15 seconden. Het telkens appenden van een string op een jTextArea bij een tekstfile van 10MB duurt een slordige 2 minuten.
Het probleem waar ik dus tegenaan loop is dat mijn GUI dus mooi een tijdje blijft hangen. (Net zoals Notepad)
Wellicht dat ik het zo laat. (Openen van de 100MB tekstfile duurt in notepad zo'n 40 seconden
)Edit: Als je de StringBuffer een begingrootte heeft kun je nog wat extra performance eruit persen. Ofwel:
StringBuffer sb = new StringBuffer(18000000); //array van 18000000 tekens
Een StringBuilder is in veel gevallen trager als een StringBuffer heb ik gemerkt.
Ook moet je dit niet doen:
Java:
1
2
3
4
5
6
| String s = ""; for(int i = 1; i < 99999; i++) { s += i + "\n"; } jTextArea1.append(s); |
Dat is ook enorm traag.
[ Voor 15% gewijzigd door Twazerty op 06-10-2009 11:22 ]
Ruisende versterker: schakel je subwoofer in.
^^ En dan heeft een aparte thread dus wél nut (los van de vraag of het nuttig is om 10 miljoen regels in een textarea te mikkeren...). Als overigens de .setText (of .append of whatever) alsnog 15 seconden nodig heeft om z'n (interne) werk te doen schiet je nog steeds geen fluit op met een aparte thread.
Nogal wiedes. En StringBuilders/Buffers zijn er natuurlijk niet voor niets
[ Voor 66% gewijzigd door RobIII op 06-10-2009 11:25 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Ok, even quick and dirty hoe je in Swing vanaf een GUI processen hoort te starten met eventuele tussentijdse updates, etc, etc.
Ja, voor sommige zaken is dit overkill, maar voor echt lang lopende background processen is dit wel de manier om het te doen.
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| final JTextArea textArea = new JTextArea(); final JProgressBar progressBar = new JProgressBar(); SwingWorker<String, String> worker = new SwingWorker<String, String>() { @Override protected String doInBackground() throws Exception { // background shizzle StringBuffer sb = new StringBuffer(); for (int i = 1; i < 99999; i++) { sb.append(i).append("\n"); if (i % 1000 == 0) { // publish tussentijdse updates publish(sb.toString()); // set progress van deze worker // een progress bar kan dus 'luisteren' naar updates van deze progress setProgress((int)(i*0.001)); } } return sb.toString(); } @Override protected void process(List<String> chunks) { // process the tussentijdse udpates and update gui // dit wordt ook netjes op de event dispatcher thread uitgevoerd for (String chunk : chunks) { textArea.append(chunk); } } @Override protected void done() { // klaar met processen, update the gui try { textArea.setText(get()); } catch (Exception ignore) { } } }; worker.addPropertyChangeListener(new PropertyChangeListenerProxy("progress", new PropertyChangeListener() { @Override public void propertyChange(PropertyChangeEvent evt) { progressBar.setValue((Integer) evt.getNewValue()); // progressbar updates hier } })); worker.execute(); |
Ja, voor sommige zaken is dit overkill, maar voor echt lang lopende background processen is dit wel de manier om het te doen.
Neem je whisky mee, is het te weinig... *zucht*
600000 regels is niet de bedoeling maar wel mogelijk. Programma moet er wel tegen kunnen zeg maar. Voornamelijke doel is dat je een gedeelte van je filesystem inleest en er iets mee doet. Bv even je filmlijst in een text bestandje knikkeren. (Recursief mappen doorlopen ed) Of even een lijst maken van al je albums. (Alleen folders lezen) Een app dat vanalles kan met je files. Als mensen toch hun hele C tree in willen lezen ga ik direct naar een file schrijven. Zonder weergave. Maar 50000 regels is geen uitzondering. Bv een muziekcollectie komt daar makkelijk aan.
Alleen loop nog tegen memory problemen aan. Windows clipboard die geen 60MB plain text pakt (Vanuit java naar windows clipboard schrijven) en gewoon java VM ram problemen. Word volgens mij door jTextArea veroorzaakt. Ga nog wel allerlei oplossingen bedenken. (Max aantal regels inlezen ed) maar voor nu:
Ik doe het omdat het kan
Wil graag de problemen tegenkomen. (Ben nog student)Edit: het editen binnen een jTextArea gaat overigens wel snel ondanks dat er 1.2 miljoen regels in staan nu
als je de wrap maar uit hebt staan. Die zorgt voor trage repaints.
[ Voor 5% gewijzigd door Twazerty op 06-10-2009 15:16 ]
Ruisende versterker: schakel je subwoofer in.
Thanks voor deze uitleg, hoop dat de TS er ook wat aan heeft. Handig dat die swingworkers dus zelf voor je invoken op het main thread (bij done).:
[...]
Nope, die crossthread exceptions (ofwel: concurrent modification exceptions) krijg je niet als je de swingworkers correct gebruikt.
De swingworker heeft 2 core methodes die je kan overriden: 'doInBackground()' en 'done()'
'doInBackground()' Wordt uitgevoerd in een managed threadpool en dat is dus de plek om je zware werk te offloaden.
Wil je gui updates doen nadat je werk klaar is, dan doe je dat via de 'done()' methode. Deze wordt uitgevoerd op de normale event dispatch thread en komt dus netjes in een queue van gui updates.
Wil je toch tijdens een background task tussendoor je gui updaten, doe je dat via 'SwingUtilities.invokeLater(Runnable doRun)'
Dat is de manier om direct iets op de event dispatcher te queuen.
Nogmaals: standaard code uitvoer in swing wordt altijd op de event dispatch thread uitgevoerd en blokkeert dus alle gui updates tot de code klaar is. (totale blokkade dus)
Pagina: 1