vb = langsam

Seite 1 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/vb_langsam_33660/page_1 - zur Vollversion wechseln!

FMFlash schrieb am 07.05.2002 um 17:18

ich hab mir aus langeweile ein eigenes kleines burn-in proggy gebastelt, mit dem ich gerade mal 0,7 "mkeys" (sogar nur einfache additionen, axp 1600+ nicht oced) zambring
da bringt der dnet client locker das 7-fache, obwohl der zusätzlich noch viel mehr rechenarbeit pro key verrichten muss

für alle dies intressiert hab ich das proggy attached

schrieb am 07.05.2002 um 17:24

vb ist so ziemlich das langsamste das es gibt :rolleyes:

FMFlash schrieb am 07.05.2002 um 17:50

oje wie langsam muss dann erst ein in vb gecodetes 3d-game sein?

jives schrieb am 07.05.2002 um 18:10

sourcecode? :rolleyes:

Ringding schrieb am 07.05.2002 um 18:10

Geh bitte, was soll man mit einem Exe anfangen? Ich weiß weder, was es macht, noch wie du's programmiert hast. Post den Sourcecode. Würd mich wundern, wenn man's nicht deutlich beschleunigen könnte.

othan schrieb am 07.05.2002 um 19:25

Zitat von .deRElict.
vb ist so ziemlich das langsamste das es gibt

got Java?

Solche Burn-In Proggis muss in C (C++) proggen... wennst da sauber machst bist um einiges schneller als in vb

/EDIT: Bei "Reset" zeigt er erst an -Wert bei mkeys an bevor er auf 0 wechselt...

der source würd mi a interresiern...

Frys_Assassin schrieb am 07.05.2002 um 21:31

hmmm...
also für solche proggys is vb definitiv sie falsche sprache... vb is optimal für gui's usw...
für deinen anwendungsplan wäre c++ am besten, mit viiiel assambler teil... weil die programmiersprachen produzieren beim kompilieren teilweise ziemlich viel overhead, sprich "langsameren" code... da bist besser dran wenn du selber den überblick bewahrst und in assembler codest... is aber a bissi anspruchsvoller als vb

FMFlash schrieb am 07.05.2002 um 22:25

huh nur leider kann ich kein assembler und meine c-zeiten sind schon lange her

hier der source, vielleicht lässt sich ja was verbessern, freu mich über jeden guten tip
übersichtlich isses auch noch, da ja ein sehr kleines proggy - auch ohne notes

FMFlash schrieb am 07.05.2002 um 22:28

Zitat von Ringding
Geh bitte, was soll man mit einem Exe anfangen? Ich weiß weder, was es macht, noch wie du's programmiert hast.

a) ausführen
b) got paranoia? is schon kein killerprog das deinen comp killt ... :rolleyes:

Ringding schrieb am 07.05.2002 um 22:31

Ich behalte mir das Recht vor, paranoid zu sein. Außerdem, was hab ich davon, es auszuführen? Ich bin dann nicht schlauer als vorher, wenn ich nicht weiß, was da abläuft.

FMFlash schrieb am 07.05.2002 um 22:37

das prog war auch nur eine demonstration der langsamkeit von vb + wenn du den source brauchst, jetzt steht er bereit

Ringding schrieb am 07.05.2002 um 22:41

Das ist deshalb so langsam, weil du ständig DoEvents aufrufst. Da wartet er halt, bis was passiert, und wenn nix passiert, dann wartet er sehr lang. In VB 6 kann man das, was du anscheinend willst - eine Hintergrundberechnung nämlich, wobei das UI weiter aktiv bleibt -, nicht vernünftig machen. Mit ein bisschen COM Trickserei und Komponenten in C(++) vielleicht, aber da muss man schon sehr genau wissen, was man tut. Mit VB.NET ginge es problemlos.

Andererseits kannst du dein Programm schon um einiges besser gestalten, wenn du DoEvents nur nach allen paar Millionen Berechnungen mal aufrufst. Sooo langsam ist compiliertes VB nämlich auch nicht.

FMFlash schrieb am 07.05.2002 um 22:53

vb.net ?

ps: danke für den super tip! die optimierung schränkt die funktion im hintergrund in keinster weise ein und jetzt schafft der hobel immerhin 14 - 15 mkeys

Ringding schrieb am 07.05.2002 um 23:08

http://msdn.microsoft.com/vbasic/

FMFlash schrieb am 07.05.2002 um 23:20

ich glaub ich bau auch mal eine kleine benchmark-funktion ein ...