AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi Procedure vs Function, Vor- und Nachteile

Procedure vs Function, Vor- und Nachteile

Ein Thema von KodeZwerg · begonnen am 15. Apr 2018 · letzter Beitrag vom 22. Apr 2018
Antwort Antwort
Seite 9 von 9   « Erste     789
günni0

Registriert seit: 7. Mär 2018
260 Beiträge
 
#81

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 10:52
Ich weiß nicht ob das hier ins Thema passt. Aber schlagt ihr die Hände über dem Kopf zusammen wenn man Funktionen benutzt wie eine Prozedur?
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
307 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#82

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 18:09
Nein.

Ich sehe heute sehr wenige bis gar keine Vorteile darin Extended Syntax nicht zu verwenden. {X-} bringt es nicht.

Wenn jemand die strikte Verwendung eines Funktionsergebnisses will erzwingen, sei es drum. Am Ende schwirren entweder zuviele Variablen rum die keiner (ge)braucht oder eine die nichts aussagt.

Ich weiß nicht ob das hier ins Thema passt. Aber schlagt ihr die Hände über dem Kopf zusammen wenn man Funktionen benutzt wie eine Prozedur?
  Mit Zitat antworten Zitat
günni0

Registriert seit: 7. Mär 2018
260 Beiträge
 
#83

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 19:15
Ich bin mir ehrlich gesagt nicht sicher, ob ich deinen Beitrag verstanden habe Michael.
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg
Online

Registriert seit: 1. Feb 2018
446 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#84

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 20:26
Also wenn man eine Funktion nicht auswertet, sprich: wie eine Prozedur bedient, da frag ich mich ob ein Result nicht doch wichtig sein könnte
Gruss vom KodeZwerg
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
5.849 Beiträge
 
Delphi 7 Personal
 
#85

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 22:17
NaJa, nimm an Du hast eine Funktion, die einen Namen von irgendwas zurückliefert. Im Fehlerfall ist dieser String leer. Dann reicht es oft zu wissen, daß ein leerer String zurück geliefert wurde. Der genaue Fehler ist dann nur noch von untergeordnetem Interesse.
(Bis dann doch noch zwei Versionen später der genaue Fehlercode relevant wird.)

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
günni0

Registriert seit: 7. Mär 2018
260 Beiträge
 
#86

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 22:59
Also wenn man eine Funktion nicht auswertet, sprich: wie eine Prozedur bedient, da frag ich mich ob ein Result nicht doch wichtig sein könnte
Ist bei mir eine Funktion die ein Formular modal oder nicht modal anzeigt, je nach Parameter. Wird nur Show statt ShowModal aufgerufen, brauche ich das Resultat nicht. Daher dieser "Funktion als Prozedur"-Missbrauch.
  Mit Zitat antworten Zitat
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
210 Beiträge
 
Delphi XE5 Professional
 
#87

AW: Procedure vs Function, Vor- und Nachteile

  Alt Gestern, 23:53
Moin moin zum Benchen hab ich für andere Beispiele das GetTick von Agner Fog genommen. Es kommt kein Zeitwert raus aber ein Wert mit dem man arbeiten kann. Getestet mit VAR OUT CONST hab ich es selbst noch nicht aber bei Bedarf kann ich es Nachreichen.
...was nicht notwendig ist, denn man hat ja immer die GetTickCount-Routine von Windows. Diese ist in der RTL schön gewrappt und abrufbar. Hab mir da so ein schönes stückchen Code gebastelt, das im grunde für fast alles anwendbar ist und mit dem ich für jede beliebige Routine ohne viel Anpassarbeit immer die Performance Ablesen kann. Das, auf diesen Fall zugeschnitten, sieht bei mir dann so aus:

Delphi-Quellcode:
const
  amount = 1000000;
  attempts = 50;
var
  x,y: cardinal;
  tickstart, tickfinish: cardinal;
  allcounts: cardinal; s: String;
begin
  allcounts := 0;
  for x := 1 to attempts do
  begin
    y := 1;
    tickstart := GetTickCount;
    while y <= amount do
    begin
      Randomize;
      SetLength(s, Random(255));
      //entw Foo(s);
      //oder FooC(s);
      //oder FooV(s);
      inc(y);
    end;
    tickfinish := GetTickCount;
    allcounts := allcounts + tickfinish - tickstart;
  end;
  showmessage(inttostr((allcounts div attempts)));
end;
Ja, ich weiß, Code qualität und Formatierung zum Kotzen, aber darauf kommt es hier idF mal nicht an.
Was hier geschieht, kurz und Knackig: Es wird eine der drei Routinen 1000000 mal hintereinander aufgerufen und von diesen Aufrufen die insgesamte Zeit (Ticks) gemessen. Das ganze wird 50 mal ausgeführt, und das Endergebnis am Ende durch 50 geteilt. So hat man einen Durchschnittswert, der auf 50 Versuchen basiert, und die Zeit für 1000000 Aufrufe widergibt. Der String besitzt immer eine Zufallslänge zwischen 0 und 255, die vor jedem Funktionsaufruf neu ausgewürfelt wird.

Die Testroutinen waren für die Erste Versuchsreihe wie folgt deklariert:

Delphi-Quellcode:
procedure Foo(S: String);
begin

end;

procedure FooC(const S: String);
begin

end;

procedure FooV(var S: String);
begin

end;
Die Ergebnisse waren beeindruckend, wenn man es so beschreiben will:
  • Für Foo(s): 77 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooC(s): 48 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooV(s): 48 Ticks je 1000000 Aufrufe im Schnitt

Nun habe ich Statt Unicode- Ansi-Strings genommen. Der Benchmark lief wie folgt ab:
  • Für Foo(s): 74 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooC(s): 50 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooV(s): 50 Ticks je 1000000 Aufrufe im Schnitt

Bei ShortString, so dachte ich mir, könne man sogar noch mehr Performance herausholen. So testete ich dies ebenfalls:
  • Für Foo(s): 64 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooC(s): 39 Ticks je 1000000 Aufrufe im Schnitt
  • Für FooV(s): 39 Ticks je 1000000 Aufrufe im Schnitt

Es scheint, als dass in den meisten Fällen, die bei zufälligen Stringlängen generiert wurden, "const" und "var" sich identisch verhalten, oder zumindest eine identische Performance besitzen. Hervorstechen tut ganz klar Foo, und zwar im negativen Sinne.

Im allgemeinen kann man grob geschätzt sagen, dass sich mit "const" die Performance bei UnicodeStrings (um 37,7%), bei AnsiStrings (um 32,4%), sowie bei ShortStrings (um 39,1%) steigern lässt. Verallgemeinert lässt sich hier eine Tendenz von etwas über einem Drittel im Schnitt feststellen. Zwischen "var" und "const" konnte in dieser Testreihe kein merklicher Unterschied festgestellt werden. Ich gehe davon aus, dass dies nur bei genauerer bestrachtungsweise der String-Länge passieren kann. Darauf, das zu überprüfen, habe ich aber im Augenblick leider keinen Bock, weshalb die Fragestellung hier offen bleibt. Evtl kann ja jemand anderes hier aushelfen...?
Dennis

Geändert von Dennis07 (Gestern um 23:57 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg
Online

Registriert seit: 1. Feb 2018
446 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#88

AW: Procedure vs Function, Vor- und Nachteile

  Alt Heute, 07:41
Kleiner Bench Verbesserungs-Vorschlag
Delphi-Quellcode:
const
  amount = 1000000;
  attempts = 50;
var
  x,y: cardinal;
// tickstart, tickfinish: cardinal;
  ticks: cardinal; // eine variable genügt
// allcounts: cardinal;
  s: String;
begin
  Randomize; // einmal reicht, oder?
  SetLength(s, Random(255)); // lieber nur ein random um ein ein präziseres ergebniss zu erhalten, man will ja nicht random benchen
// allcounts := 0;
  for x := 1 to attempts do
  begin
    y := 1;
    ticks := GetTickCount;
// tickstart := GetTickCount;
    while y <= amount do
    begin
// Randomize;
// SetLength(s, Random(255));
      //entw Foo(s);
      //oder FooC(s);
      //oder FooV(s);
      inc(y);
    end;
// tickfinish := GetTickCount;
// allcounts := allcounts + tickfinish - tickstart; // 0 + tickdifferenz
    ticks := GetTickCount - ticks;
  end;
// showmessage(inttostr((allcounts div attempts)));
  showmessage(inttostr((ticks div attempts)));
end;
Ich habe es noch nicht getestet aber so erscheint es mir logischer
Gruss vom KodeZwerg
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
34.254 Beiträge
 
Delphi XE3 Professional
 
#89

AW: Procedure vs Function, Vor- und Nachteile

  Alt Heute, 08:26
Uhrzeit (GetSystemTime und Andere) - maximal Millisekunden
GetTickCount - meistens 15-16 Millisekunden
QueryPerformanceCounter - schnell, x Nanosekunden
RDTSC (Read Time-Stamp Counter) - schneller, es waren mal CPU-Ticks

TThread.GetTickCount - bestimmt GetTickCount
TStopwatch - QueryPerformanceCounter im Windows
(TPlatformServices.Current as IFMXTimerService).GetTick - QueryPerformanceCounter im Windows
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (Heute um 08:37 Uhr)
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
307 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#90

AW: Procedure vs Function, Vor- und Nachteile

  Alt Heute, 09:09
Können schon.

Rückgabewerte kommt vom alten C, denn da hatte ein Funktion immer den Rückgabewert int sofern nichts definiert war und nicht void.

---

Aber du kannst in Delphi/Pascal ein Ergebnis ja auswerten.

Allein war im Pascal früher die Verwendung der Rückgabe verpflichtend. Das führte dazu, dass wie kurz zuvor erwähnt viele Statusvariablen rumschwirrten die entweder das Ergebnis des letzten Funktionsaufrufs hielten oder es gab viele davon. Das machte die Programme unübersichtlich und fehleranfällig.

Alternative hast du zuviele IFs die sich mit Fehlerbehandlung beschäftigen oder die typischen MagicHandleError(Funktion(A,B)); als Ersatz für eine Exception (kinda GOTO :ERROR).


--

Damals waren Prozeduren lange und Nested Procedures waren an der Tagesordnung.

Im Delphi kannst du in einem Testprojekt mal Erweiterte Syntax auf 'false' setzen in den Optionen und in der Praxis. Du wirst schnell sehen, dass die damit verbundenen Restriktionen mehr Ungemach als Gemach provozieren. Zu Zeiten von Records und Abstrakten Datenstrukturen resp. -typen war diese Modus noch durchwegs akzeptabel. Mit OO begannen die Nachteile zu überwiegen (merklich seit BP 7).



Also wenn man eine Funktion nicht auswertet, sprich: wie eine Prozedur bedient, da frag ich mich ob ein Result nicht doch wichtig sein könnte

Geändert von MichaelT (Heute um 09:12 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:23 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf