[C#] Form blijft hangen

[Verwijderd]

Ik ben bezig met een programma te maken die 2 tekst bestanden uitleest met de uitgelezen info wat berekeningen doet en dit dat weer weg schrijft naar een tekst bestand.

De 2 tekst bestanden bestaan uit 750 punten met elk 3 sub punten. Het idee is dat elk punt uit bestand 1 vermenigvuldigt wordt met elk punt uit bestand 2. Dus uiteindelijk heb je (750*3)^2 = 5062500 punten.
Bij ieder punt hoort een positie die voor het punt in het bestand staat.

voorbeeld van een punt:
Position 100 5000 5000, nselect = 1, pselect = 1
0.01592 -0.03905 0.85214 -0.47831 0.45320 -0.87230 -0.00262 -0.03277
-0.03445 0.02402 -0.07610 -0.96864 -0.57427 -0.78662 -0.02381 0.01892
-0.00326 -0.00437 -0.90877 -0.36031 -0.92687 -0.33179 -0.00414 -0.00437

ik pak eerst de positie van bestand 1 en dan zet ik de 3 punten in een array. Daarna loop ik bestand 2 door pak iedere keer de positie en daarna doe ik de berekeningen met de juiste punten.

Bij kleinere bestanden gaat het goed maar bij dit bestand heb ik het probleem dat het programma blijft hangen. Als ik in taakbeheer kijk gaat het een tijdje goed en wordt er ongeveer de helft van processor gebruikt. Maar daarna dropt het processor gebruik naar +/-4% en wordt er binnen no time 500mb geheugen gebruikt. Dit fluctueert dan een beetje maar er gebeurd verder niks meer.

Zoals ik het nu doe is

C#:

            StreamWriter sw = new StreamWriter(sHarmonicsFilePath);
            StreamReader srTuner1 = new StreamReader(sTuner1FilePath);
            StreamReader srTuner2 = new StreamReader(sTuner2FilePath);
            //While not end of file.
            while (!srTuner1.EndOfStream)
            {
                sInputTuner1 = srTuner1.ReadLine();

//als de positie gepakt is doe dit.
                if (bPosition1)
                {
                    if (j == iNumberOfHarm)
                    {
                        sArrayTuner1[j] = sInputTuner1;
                        
                        while (!srTuner2.EndOfStream)
                        {
                            sInputTuner2 = srTuner2.ReadLine();

                            if (sFrequency1.Equals(sFrequency2))
                            {
                                if (bPosition2)
                                {
//pak punt uit bestand 1                                    
sSplit = sArrayTuner1[k].Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);

//doe berekening
sCascade = //berekening                                    

                                    sCommandline = sCascade.Replace(',', '.');
                                    sw.WriteLine(sCommandline);
                                    
                                    //zorg dat het volgende punt uit punten bestand 1 gebruikt wordt
                                    if (k == iNumberOfHarm)
                                    {
                                        bPosition2 = false;
                                    }
                                    k++;
                                }

                                //get position of tuner 2
                                if (sInputTuner2.Contains("Position"))
                                {
                                    bPosition2 = true;
                                    k = 0;
                                    sSplit = sInputTuner2.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
                                    sCommandline = sPosition + " Tuner2 L = " + sSplit[1] + " P1 = " + sSplit[2] + " P2 = " + sSplit[3].Replace(',', ' ').TrimEnd();
                                    sw.WriteLine(sCommandline);
                                }
                            }
                        }

                        //reset the stream of tuner file 2
                        srTuner2.BaseStream.Position = 0;
                        srTuner2.DiscardBufferedData();
                        bPosition1 = false;
                    }
                    else
                    {
                        sArrayTuner1[j] = sInputTuner1;
                        j++;
                    }
                }

                //pak positie van bestand 1 
                if (sInputTuner1.Contains("Position"))
                {
                    j = 0;
                    bPosition1 = true;
                    sSplit = sInputTuner1.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
                    sPosition = " ! Position Tuner1 L = " + sSplit[1] + " P1 = " + sSplit[2] + " P2 = " + sSplit[3].Replace(',', ' ').TrimEnd();
                }
            }

            //close streams
            srTuner1.Close();
            srTuner2.Close();
            sw.Close();

Heeft er iemand een idee hoe het efficiënter kan? Ik denk dat daar het probleem ligt aangezien het met kleinere bestanden wel werkt.
Of heeft iemand een ander idee waar het aan kan liggen?

Alvast bedankt voor jullie moeite.

[Verwijderd]

Je verwerkt alles in één thread? Als je dat doet, dan blijft het programma hangen totdat hij klaar is met het rekenen. Hij zou dan ook bij grote bestanden uiteindelijk wel een keer af moeten komen.

[epic007]

Het lijkt mij ook wel slimmer om eerst je files in te lezen in een datastructuur, en daar dan je berekeningen op los te laten.

C#:

class Position
{
....
}

List<Position> positions;

while (!eof)
{
positions.Add(new Position(....));
}

[theblindman]

Een multithreaded aanpak is hier eigenlijk het mooist .
Kijk eens naar de BackgroundWorker component, die kan je hierbij vast helpen... (of je gebruikt System.Threading natuurlijk )

[Verwijderd]

theblindman schreef op maandag 13 december 2010 @ 15:27:
Een multithreaded aanpak is hier eigenlijk het mooist .
Kijk eens naar de BackgroundWorker component, die kan je hierbij vast helpen... (of je gebruikt System.Threading natuurlijk )

Bedankt voor de tip. Heb er geen ervaring mee dus zal er eens naar gaan kijken.

[Verwijderd]

epic007 schreef op maandag 13 december 2010 @ 15:12:
Het lijkt mij ook wel slimmer om eerst je files in te lezen in een datastructuur, en daar dan je berekeningen op los te laten.

Heb ik ook over na gedacht maar is dat sneller dan het uitlezen van een file? Het aantal berekeningen dat je moet doen blijft toch hetzelfde?

[Phyxion]

C#:

ThreadPool.QueueUserWorkItem(new WaitCallback(FunctieMetLapTextZoalsHierboven));

Je kan het ook met anonymous delegate doen:

C#:

ThreadPool.QueueUserWorkItem(delegate()
{
        // Hele lap text
});

Hou er wel rekening mee dat je waarschijnlijk een Invoke moet gebruiken als je met meerdere threads werkt als je de gegevens in je form wilt laten zien, anders krijg je een cross thread exception.

[Down]

Phyxion schreef op maandag 13 december 2010 @ 15:57:

C#:

ThreadPool.QueueUserWorkItem(new WaitCallback(FunctieMetLapTextZoalsHierboven));

Je kan het ook met anonymous delegate doen:

C#:

ThreadPool.QueueUserWorkItem(delegate()
{
        // Hele lap text
});

Hou er wel rekening mee dat je waarschijnlijk een Invoke moet gebruiken als je met meerdere threads werkt als je de gegevens in je form wilt laten zien, anders krijg je een cross thread exception.

Waarom gewoon niet een backgroundworker? Die heeft al een aantal makkelijke zaken aan boord zoals de ProgressChanged, RunWorkerCompleted en IsBusy

[theblindman]

Verwijderd schreef op maandag 13 december 2010 @ 15:52:
[...]


Heb ik ook over na gedacht maar is dat sneller dan het uitlezen van een file? Het aantal berekeningen dat je moet doen blijft toch hetzelfde?

Een HDD blijft natuurlijk veeeel trager dan werkgeheugen. Als je het goed wilt doen, is de hierboven omschreven manier denk inderdaad wel de beste .

[Bolukan]

Try it (and report here )

[message]http://msdn.microsoft.com/en-us/library/system.io.streamreader.discardbuffereddata.aspx[/message]

Use the DiscardBufferedData method to reset the internal buffer for the StreamReader object. You need to call this method only when the position of the internal buffer and the BaseStream do not match. These positions can become mismatched when you read data into the buffer and then seek a new position in the underlying stream. This method slows performance and should be used only when absolutely necessary, such as when you want to read a portion of the contents of a StreamReader object more than once.

[Reptile209]

Even los van hoe het anders zou kunnen: hoe heb je al geprobeerd om dit te debuggen? Bijvoorbeeld met een tellertje dat elke x punten een update op je form geeft (wel even een DoEvents() of ProcessMessages() of hoe dat ook in C# heet doen)? Of de voortgang in een los tekstbestandje loggen?

Dan kan je tenminste zien wat er gebeurt en of hij vastloopt of dat er ergens anders een bottle-neck zit. Je wil 5 miljoen punten maal X tekens per punt wegschrijven, dan zit je aan enkele tientallen megabytes. Dat zou geen punt moeten mogen zijn, ongeacht je oplossing.

[Haan]

Is er überhaupt een reden om dit in een forms applicatie te doen ipv bijvoorbeeld een console applicatie?

[theblindman]

Haan schreef op maandag 13 december 2010 @ 19:08:
Is er überhaupt een reden om dit in een forms applicatie te doen ipv bijvoorbeeld een console applicatie?

Misschien omdat het gebruiksvriendelijker kan zijN?
Of gewoon, omdat het kan

[Haan]

theblindman schreef op maandag 13 december 2010 @ 19:15:
[...]

Misschien omdat het gebruiksvriendelijker kan zijN?
Of gewoon, omdat het kan

Als het programma alleen bestanden in leest, iets berekent en dat weer weg schrijft heb je niet persé een GUI nodig. Je ziet wat voor extra rompslomp dat geeft.

[Sebazzz]

Reptile209 schreef op maandag 13 december 2010 @ 16:18:
Even los van hoe het anders zou kunnen: hoe heb je al geprobeerd om dit te debuggen? Bijvoorbeeld met een tellertje dat elke x punten een update op je form geeft (wel even een DoEvents() of ProcessMessages() of hoe dat ook in C# heet doen)? Of de voortgang in een los tekstbestandje loggen?

DoEvents is niet aan te raden.

http://www.codinghorror.c.../12/is-doevents-evil.html

[Reptile209]

Sebazzz schreef op maandag 13 december 2010 @ 19:49:
[...]

DoEvents is niet aan te raden.

http://www.codinghorror.c.../12/is-doevents-evil.html

Ammehoela. De TS weet nog niet eens waar zijn probleem precies zit. Dan is het toch veel makkelijker om - via DoEvents() - te testen of threading zou kunnen helpen, dan om eerst je hele programma te gaan ombouwen naar multithreaded? Inclusief alle synchronisatie-issues waar 'ie dan tegenaan loopt? Als DoEvents() weinig of geen verbetering geeft, dan zullen meerdere threads dat waarschijnlijk ook niet doen. Als het wel helpt, dan is het de moeite om je in threading te verdiepen en de boel om te gooien.

[ Voor 12% gewijzigd door Reptile209 op 14-12-2010 06:41 ]

[Verwijderd]

Haan schreef op maandag 13 december 2010 @ 19:08:
Is er überhaupt een reden om dit in een forms applicatie te doen ipv bijvoorbeeld een console applicatie?

Dit is 1 van de dingen die het programma moet doen. Voor de rest is er wel een UI nodig.

[Verwijderd]

Ik heb het nu multithreaded geprobeerd maar daar wordt het alleen trager van...

Zoals ik het heb gedaan is
Ik lees eerst in 2 threads de beide files 2 aparte lists
Daarna loop ik de lists na en bereken ik in 3 threads de punten.

C#:

Thread threadFile1 = new Thread(new ThreadStart(readFile1));
Thread threadFile2 = new Thread(new ThreadStart(readFile2));

threadFile1.Start();
threadFile2.Start();

while (threadFile1.ThreadState == System.Threading.ThreadState.Running || threadFile2.ThreadState == System.Threading.ThreadState.Running) { }

foreach (classFileData Y in FileData1)
{
     foreach (classFileData Z in FileData2)
     {         
         Thread r1 = new Thread(new ThreadStart(calcR1));
         Thread h2r1 = new Thread(new ThreadStart(calcH2R1));
         Thread h3r1 = new Thread(new ThreadStart(calcH3R1));
         Thread h4r1 = new Thread(new ThreadStart(calcH4R1));

          //de berekeningen
          r1.Start();
          h2r1.Start();
          h3r1.Start();
          h4r1.Start();

          while (r1.ThreadState == System.Threading.ThreadState.Running || h2r1.ThreadState == System.Threading.ThreadState.Running || h3r1.ThreadState == System.Threading.ThreadState.Running || h4r1.ThreadState == System.Threading.ThreadState.Running) { }

          //schrijf alles weg naar file
     }
}

Doe ik iets verkeerd waardoor het trager wordt?

[ Voor 32% gewijzigd door Verwijderd op 14-12-2010 15:24 ]

[Haan]

Verwijderd schreef op dinsdag 14 december 2010 @ 15:20:
Ik heb het nu multithreaded geprobeerd maar daar wordt het alleen trager van...

Zoals ik het heb gedaan is
Ik lees eerst in 2 threads de beide files 2 aparte lists
Daarna loop ik de lists na en bereken ik in 3 threads de punten.

C#:

Doe ik iets verkeerd waardoor het trager wordt?

Zoals al is gezegd, heb je hiervoor de BackgroundWorker class.

[boe2]

Verwijderd schreef op dinsdag 14 december 2010 @ 15:20:
Doe ik iets verkeerd waardoor het trager wordt?

Ik denk dat je de bedoeling van threading niet volledig snapt

In de code die je nu post start je een aparte thread, maar je blijft in je main thread (waarin ook je GUI draait) wachten tot die andere thread is uitgevoerd: Hij zal dus evenveel "pauzeren" als wanneer je het gewoon in dezelfde thread zou draaien.
Wat je moet doen is de thread starten en via een delegate de resultaten terugsturen naar je mainthread

Zoals hierboven al aangegeven: Het gemakkelijkste is om met een backgroundworker te werken. Dat spaart je wat kopzorgen uit ivm events en delegates

[Zeebonk]

Als ik de code hierboven zie word dit nog steeds uitgevoerd in de thread van de form. Dus de form thread wacht nog steeds totdat de berekeningen etc gedaan zijn, waardoor het nog steeds lijkt alsof het formulier "hangt". Door één extra thread te maken en daar de code zoals in je eerst post in te stoppen zal het formulier responsief blijven en de berekening etc evengoed worden uitgevoerd.

Dat het nu trager gaat komt waarschijnlijk door de overhead van de threads die je hebt aangemaakt.

Voor de rest ben ik het met Down eens dat het handig is hiervoor een Backgroundworker te gebruiken omdat deze handige event's e.d. aan boord heeft.

[ Voor 0% gewijzigd door Zeebonk op 14-12-2010 15:53 . Reden: Haan & Boeboe waren mij te snel af :( ]

[Verwijderd]

Ik dacht dat het door gebruik van meerdere threads misschien ook sneller zou gaan maar dat heb ik dus verkeerd begrepen. Dan ga ik nu maar verder met de backgroundworker

[farlane]

Verwijderd schreef op dinsdag 14 december 2010 @ 16:03:
Ik dacht dat het door gebruik van meerdere threads misschien ook sneller zou gaan maar dat heb ik dus verkeerd begrepen. Dan ga ik nu maar verder met de backgroundworker

Dat is alleen het geval als je taken hebt die je kunt parallelliseren. In de meeste andere gevallen is het gebruik van meerdere threads eerder langzamer ( zoals het inlezen van 2 bestanden tegelijk )

[Down]

Sebazzz schreef op maandag 13 december 2010 @ 19:49:
[...]

DoEvents is niet aan te raden.

http://www.codinghorror.c.../12/is-doevents-evil.html

Kan prima werken in dit geval. Ik kan het alleen maar eens zijn met de conclusie van het artikel:

I agree that DoEvents is not exactly great programming practice, but even Microsoft recommends using it in lieu of hard-core threading for simple problems. So it's something of a tradeoff. Easier WinForms threading is coming in .NET 2.0, but in the meantime, I'd look into the backgroundworker code samples.

De backgroundworker maakt uiteraard een hoop goed, maar kreten als "DoEvents is evil" vind ik altijd zo zwart-wit.

[TallManNL]

Verwijderd schreef op dinsdag 14 december 2010 @ 15:20:

C#:

foreach (classFileData Y in FileData1)
{
     foreach (classFileData Z in FileData2)
     {         
         Thread r1 = new Thread(new ThreadStart(calcR1));
         Thread h2r1 = new Thread(new ThreadStart(calcH2R1));
         Thread h3r1 = new Thread(new ThreadStart(calcH3R1));
         Thread h4r1 = new Thread(new ThreadStart(calcH4R1));

          //de berekeningen
          r1.Start();
          h2r1.Start();
          h3r1.Start();
          h4r1.Start();

          while (r1.ThreadState == System.Threading.ThreadState.Running || h2r1.ThreadState == System.Threading.ThreadState.Running || h3r1.ThreadState == System.Threading.ThreadState.Running || h4r1.ThreadState == System.Threading.ThreadState.Running) { }

          //schrijf alles weg naar file
     }
}

Kijk ik hier nou verkeerd of start je voor iedere punt berekening nieuwe threads?
Als iedere foreach die je hebt staan 750 iteraties kent ben je dus een paar miljoen threads aan het aanmaken en starten. Thread starten heeft nogal een overhead dus je wil je threads langer laten lopen en niet telkens opnieuw aanmaken/starten.
Je kunt beter een thread starten die je de eerste 250 items uit je FileData1 geeft, deze thread doet te berekeningen voor deze 250 items, de andere threads die je start geef je ieder hun eigen subset van FileData1.
Zolang je niet in FileData2 schrijft in je threads kun je gewoon vanuit die threads tegelijk lezen ut FileData2.

[Phyxion]

TallManNL schreef op woensdag 15 december 2010 @ 10:15:
[...]


Kijk ik hier nou verkeerd of start je voor iedere punt berekening nieuwe threads?
Als iedere foreach die je hebt staan 750 iteraties kent ben je dus een paar miljoen threads aan het aanmaken en starten. Thread starten heeft nogal een overhead dus je wil je threads langer laten lopen en niet telkens opnieuw aanmaken/starten.
Je kunt beter een thread starten die je de eerste 250 items uit je FileData1 geeft, deze thread doet te berekeningen voor deze 250 items, de andere threads die je start geef je ieder hun eigen subset van FileData1.
Zolang je niet in FileData2 schrijft in je threads kun je gewoon vanuit die threads tegelijk lezen ut FileData2.

Een thread elke keer aanmaken heeft sowieso behoorlijk veel overhead, zoals ik al aangaf is een ThreadPool veel efficiënter dan een thread, met als bijkomstigheid dat er ook nog een limiet op het aantal threads zit waardoor je CPU niet helemaal plat gaat van het aantal threads. Nog een voordeel is dat de ThreadPool aangemaakte threads hergebruikt worden waardoor je niet elke keer met de overhead van het aanmaken van een nieuwe thread zit.

Als je op .NET 4.0 draait kan je ook Parallel.ForEach gebruiken.

[Verwijderd]

Phyxion schreef op woensdag 15 december 2010 @ 10:27:
[...]

Een thread elke keer aanmaken heeft sowieso behoorlijk veel overhead, zoals ik al aangaf is een ThreadPool veel efficiënter dan een thread, met als bijkomstigheid dat er ook nog een limiet op het aantal threads zit waardoor je CPU niet helemaal plat gaat van het aantal threads. Nog een voordeel is dat de ThreadPool aangemaakte threads hergebruikt worden waardoor je niet elke keer met de overhead van het aanmaken van een nieuwe thread zit.

Als je op .NET 4.0 draait kan je ook Parallel.ForEach gebruiken.

Daarnaast is de applicatie in dit code voorbeeld zo traag als het inlezen van de grootste file + de som van de langzaamste threads. Dat haalt het idee van threading natuurlijk ook onderuit . Hij wacht namelijk elke lus op de langzaamste thread en dat gebeurt ook bij het inlezen.

[Verwijderd]

Het is denk ik handig om even te kijken waar de kern van het probleem ligt (de trage verwerking).
Een paar miljoen vermenigvuldigingen moet secondenwerk zijn in C# als je het juist doet.

Threads gaan hier niet helpen (is alleen leuk als je meerdere dingen tegelijk moet doen) ok een progress bar is leuk maar die heb je denk ik niet nodig als je progje in een paar seconden klaar is en leiden alleen af van je probleem.

Kern van het probleem is volgens mij de manier waarop je seekt in het tweede bestand. Elke poging om de juiste positie te vinden de 2e file gebeurt door een x aantal keer een sr.readline() uit te voeren. Naarmate je verder komt met de processor wordt deze x steeds eentje hoger wat je steeds lagere snelheid verklaart. Ook je cpu % gaat naar beneden omdat cpu steeds op meer IO (=traag) zit te wachten.

Een oplossing van het probleem zou imo kunnen zijn:
- lees bestand 1 in één keer in naar een string met File.ReadAllText() of zoiets, split op het woord position naar een array.
- maak een parse method die punt/subpunten regels parsed naar een Punt class
- vervolgens de array naar een List<Punt> parsen (Linq gebruiken?).
- het riedeltje hierboven doe je ook voor bestand 2.
- maak een multiply method "public Punt Multiply(Punt punt)" in je Punt class die een vermenigd Punt retourneerd
- je dubbele while lus kan je vervolgens wijzigen in:

for i=1..lijst1.Count
{
nieuw = lijst1[i].Multiply(lijst2[i]);
ws.writeline(nieuw.ToString());
}

het schrijven naar de stream zal denk ik nog het meeste vertraging opleveren, wedden dat het snel is nu?

[alex3305]

Even buiten het gebruik van Threads om. Als je weet dat je berekening altijd uit drie punten bestaat, zou ik persoonlijk hiervoor een datastructuur maken. In deze datastructuur zou ik dan PointA, PointB en PointC opslaan. Je kunt daarna een statische methode maken genaamd Calculate welke twee van deze datastructuren pakt. Even in commentaar/pseudo-code hoe ik het zou visualiseren:

code:

var txtFile1 = ReadFile("file1.txt");
var txtFile2 = ReadFile("file2.txt");

var points1 = Points.ConvertTextToPoints(txtFile1);
var points2 = Points.ConvertTextToPoints(txtFile2);

var result = Points.Calculate(points1, points2);

Waarbij je het omzetten van punten eventueel nog in threads kunt indelen en eventueel in de Point-klasse ook nog het een en ander in kunt threaden.