Langsamer Datentransfer --> wie gehts schneller???

[Ein ehemaliger Benutzer]

Hab das hier reingepostet weil ich den Datantransfer mit TServer und TClient Sockets mache.

Ich empfange Daten mit folgendem Code;

int bufsize = Socket->ReceiveLength();
 BYTE *Buffer = new BYTE[bufsize];
 Socket->ReceiveBuf(Buffer, bufsize);
 fss->Position=fss->Size;

 fss->Write(Buffer, bufsize);

Es gibt noch weiteren Code aber der wird nicht jedesmal aufgerufen außerdem betrifft es nicht das Daten-empfangen direkt.

Wie kann ich nun den code schneller machen?? Die Datentransfers gehen nämlich ziemlich langsam, und auf veralterten Rechner gehts überhaupt verdammt langsam.

Soll ich den Buffer global deklarieren, diesen dann auffüllen und dann erst in die Datei schreiben??

[junix]

Eine Möglichkeit wäre es, einen Fixen Puffer zu definieren (statt mit new zu erstellen) und diesen jeweils zu füllen. Allerdings glaube ich nicht, dass das hier der Flaschenhals sein soll.

Wie hast du diesen Code als Flaschenhals identifiziert?

-junix

[Ein ehemaliger Benutzer]

Ich empfange die Daten eben damit, und schließlich ist der Datentransfer lahm. Auch ist die CPU Auslastung recht hoch. (Was ich aber nicht deuten kann.)

Das eindeutigste ist aber der recht hohe Festplattenzugriff.

Denke mir eigentlich das es schneller wäre wenn ich größere Mengen Daten auf einmal schreibe, anstatt die kleinen Häppchen (Ich glaub 8k) gleich rein zu schreiben.

[junix]

Gen.d.Pz.Tr.Seb schrieb:

Denke mir eigentlich das es schneller wäre wenn ich größere Mengen Daten auf einmal schreibe, anstatt die kleinen Häppchen (Ich glaub 8k) gleich rein zu schreiben.

Dem ist garantiert so. Versuch mal die daten, statt direkt ins File in einen grösseren Puffer (1-2MB) zu schreiben und immer erst wenn der puffer voll ist einen Schrieb ins File durchzuführen. Und wie gesagt: new und delete sind sehr zeitraubende Aufrufe...

Einen habe ich noch: Wenn da weiterer Code steht, den das Daten empfangen direkt nicht betrifft, wieso steht der Code dann da?

-junix

[Ein ehemaliger Benutzer]

Der weitere Code berechnet und schreibt informationen zum transfer (geschwindigkeit, dauer, wie lang noch,..) in die statusbar und sendet sie auch noch zum daten-sender.

Werd mal einen größeren buffer probieren und das new und delete raushauen.

[junix]

Gen.d.Pz.Tr.Seb schrieb:

Der weitere Code berechnet und schreibt informationen zum transfer (geschwindigkeit, dauer, wie lang noch,..) in die statusbar

Die Grundsätzliche Devise bei Event-Handler sollte sein: Möglichst kurz und nur das, was unmittelbar nötig ist. (Es gelten ähnliche Regeln wie bei der Programmierung einer ISR (Interrupt Service Routine))
Du hälst die Empfangen-Prozedur nur mit unnötigen Berechnungen auf, die eigentlich sowieso nur frühestens alle 250ms benötigt werden (schnellere Updates als 4Hz sind eh uninteressant, da du sonst sowieso die längste Zeit das selbe zeichnest -> Verschwendete Rechner ressourcen).

Gen.d.Pz.Tr.Seb schrieb:

und sendet sie auch noch zum daten-sender.

Wieso denn das? Wieso rechner der nicht selber? -> Spart (unnötigen) Traffic

-junix

[Ein ehemaliger Benutzer]

Ja, aber wie könnte ich am Besten diese Zusatzinformationen berechnen?? Ich habe jetzt sowieso eine Schleife, sodass diese Zusatzinformationen nur bei jedem 30igsten empfangenen Paket erarbeitet werden.

Zum Zurücksenden;

Ich versende das beim anderen einfach so;

ClientSocket2->Socket->SendStream(fs);

Da kann ich dann nicht mehr berechnen, deswegen mach ich das beim Datenempfänger.

Achja, wenn ich einen Buffer global deklariere weise ich diesem ja eine fixe Größe zu.

Wenn ich jetzt den Buffer in den Stream schreiben will, wie kann ich das machen das nur der Teil des Buffers geschrieben wird der auch tatsächlich voll ist.

Gibts da so eine Buffer->Size?

[junix]

Gen.d.Pz.Tr.Seb schrieb:

Ja, aber wie könnte ich am Besten diese Zusatzinformationen berechnen??

In einer TImer Rooutine eines TImer der nur alle 250ms zum Zug kommt z.B.

Gen.d.Pz.Tr.Seb schrieb:

Zum Zurücksenden;

Ich versende das beim anderen einfach so;

ClientSocket2->Socket->SendStream(fs);

Da kann ich dann nicht mehr berechnen, deswegen mach ich das beim Datenempfänger.

Naja, dünkt mich sowieso suboptimal diese Art das File zu versenden... Wenns länger dauert, sieht deine Anwendung wohl etwas eingefroren aus... Ich würd da selber die Häppchen abstimmen...

Gen.d.Pz.Tr.Seb schrieb:

Achja, wenn ich einen Buffer global deklariere weise ich diesem ja eine fixe Größe zu.

Was habt Ihr nur immer mit global? Wieso sollte der Buffer Global sein? Welchen Sinn macht das Globale? Wer ausser der Klasse die deinen Socket besitzt sollte diesen Buffer denn noch verwenden?

Gen.d.Pz.Tr.Seb schrieb:

Wenn ich jetzt den Buffer in den Stream schreiben will, wie kann ich das machen das nur der Teil des Buffers geschrieben wird der auch tatsächlich voll ist.

Du weisst doch, wenn du den Puffer gefüllt hast?

Gen.d.Pz.Tr.Seb schrieb:

Gibts da so eine Buffer->Size?

Kommt ganz darauf an, wie du deinen Puffer implementierst?

Ehrlich gesagt, verstehe ich die letzten Beiden Fragen nicht wirklich.

-junix

[Ein ehemaliger Benutzer]

junix schrieb:

Gen.d.Pz.Tr.Seb schrieb:

Ja, aber wie könnte ich am Besten diese Zusatzinformationen berechnen??

In einer TImer Rooutine eines TImer der nur alle 250ms zum Zug kommt z.B.

Hab ich schon einmal gemacht, dann ist aber der Timer immer hängen geblieben weil der Prozessor so ausgelastet war.

Ich werde dann auch mal versuchen die Daten in Häppchen wegzuschicken, aber zuerst versuch ich einfach das mit dem Buffer.

[junix]

Gen.d.Pz.Tr.Seb schrieb:

junix schrieb:

In einer TImer Rooutine eines TImer der nur alle 250ms zum Zug kommt z.B.

Hab ich schon einmal gemacht, dann ist aber der Timer immer hängen geblieben weil der Prozessor so ausgelastet war.

... kaum ... viel wahrscheinlicher ist, dass die WM_TIMER-Message nicht bearbeitet werden konnte, weil du irgendwo ne schleife hast, die da nicht hingehört...

-junix