Subroutinen Performance? (Perl/CGI)

[thread]13963[/thread]

Subroutinen Performance?

Leser: 28

Articles: hide open all | hide show old branches

+13 replies
umbrella

2009-09-02 00:33

User since
2009-09-01
24 Artikel
BenutzerIn

Hallo Leute, ich wieder. :)

Ist es am sinnvollsten wenn man Subroutinen ins Hauptprogramm schreibt, wo Sie ja auch gebraucht werden - oder ist das jetzt nicht so tragisch Unterprogramme in externe Daten zu lagern, die dann wieder per do eingebunden werden?

LG, -umbrella
Wer sich stets zu viel geschont hat, der kränkelt zuletzt an seiner vielen Schonung. Gelobt sei, was hart macht!
- topeg
  
  2009-09-02 03:06
  
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  
  Ich finde, man sollte Funktionen, die zusammen gehören (Datenbankoperationen, Templatesachen, etc) zusammen packen und das als Modul verwenden. Das verbessert die Wiederverwendbarkeit, und das "use" kostet nicht so viel Zeit, dass man sich darüber Gedanken machen müsste. ach lieber ein paar Module zu viel als zu wenig.
  
  Zu deinem Beispiel mit dem Templatesystem. Bei einer guten Abstraktion kann man das ganze Templatesystem umschreiben, ohne auch nur eine Zeile an den Programmen zu ändern, die es nutzen.
  
  Ob sie objektorientiert sind oder nicht, bleibt dir überlassen. (Wobei die Objektorientierung einige Vorteile bietet)
- +2 replies
- Taulmarill
  
  2009-09-02 10:01
  
  User since
  2004-02-19
  1750 Artikel
  BenutzerIn
  
  Generell ist der Zeitaufwand für das einbinden von weiteren Dateien per do, use oder require gegenüber dem direkten einbinden in die selbe Datei wie das Hauptprogramm IMHO vernachlässigbar.
  
  do würde ich nicht benutzen. Es ist zwar erst mal die einfachste Möglichkeit, so was zu realisieren, es wird aber bei jedem Aufruf die Datei neu geladen. Wenn du ein Modul schreibst (ist gar nicht so schwer) und das per use einbindest, wird die Datei nur einmal geladen, egal wie oft du use aufrufst.
  $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
  - umbrella
    
    2009-09-02 10:36
    
    User since
    2009-09-01
    24 Artikel
    BenutzerIn
    
    Hi Leute :)
    
    Das ist echt gut, habe heute wieder ein ganze reihe an Dingen dazu gelernt. Webentwicklung ist mein Hobby, welches mir eine menge Spaß bereitet.
    Deshalb freue ich mich immer über neue Dinge, die ich in Perl und Co. dazu lerne.
    
    Meine Frage ist soweit beantwortet. :)
    Danke erstmal, Euch beiden :)
    Wer sich stets zu viel geschont hat, der kränkelt zuletzt an seiner vielen Schonung. Gelobt sei, was hart macht!
- +9 replies
- sid burn
  
  2009-09-02 10:41
  
  User since
  2006-03-29
  1520 Artikel
  BenutzerIn
  
  Auf die Laufzeit hat das einbinden gar keine Auswirkung. Evtl. beim Starten des weil dann zwei Dateien geöffnet werden müssen. Aber ehrlich, über solche unsinnige Dinge sollte man nicht wirklich darüber nachdenken.
  
  Eine generelle Regel. Nicht im vorraus optimieren. Nur dann Optimieren wenn du Performance Probleme hast, und dann nicht raten, sondern einen Profiler nutzen: Devel::NYTProf
  
  Ansonsten würde ich dir lieber Empfehlen deine Module mit "use" einzubinden und das Modul Exporter zu nutzen. Alternativ wenn du dich etwas besser auskennst würde ich dir sogar eher zu Sub::Exporter raten. Damit kann dann jeder den Funktionsnahmen selber wählen wie er ihn importieren möchte. Auch lassen sich Generatoren einfach schreiben.
  
  EDIT: Link zu "Exporter" hinzugefügt.
  Last edited: 2009-09-02 10:43:06 +0200 (CEST)
  Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - +8 replies
  - Taulmarill
    
    2009-09-02 11:13
    
    User since
    2004-02-19
    1750 Artikel
    BenutzerIn
    
    2009-09-02T08:41:53 sid burn
    Auf die Laufzeit hat das einbinden gar keine Auswirkung. Evtl. beim Starten des weil dann zwei Dateien geöffnet werden müssen. Aber ehrlich, über solche unsinnige Dinge sollte man nicht wirklich darüber nachdenken.
    
    Ich denke es geht hier um die gesamte Laufzeit des Interpreters und nicht die des Programms selbst. Bei CGI macht das schon Sinn, sich um solche Sachen Gedanken zu machen.
    
    2009-09-02T08:41:53 sid burn
    Alternativ wenn du dich etwas besser auskennst würde ich dir sogar eher zu Sub::Exporter raten.
    
    Sub::Exporter kannte ich noch nicht. Sieht aber interessant aus, muss ich mir mal näher anschauen.
    $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
    - +7 replies
    - sid burn
      
      2009-09-02 11:33
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      2009-09-02T09:13:05 Taulmarill
      Ich denke es geht hier um die gesamte Laufzeit des Interpreters und nicht die des Programms selbst. Bei CGI macht das schon Sinn, sich um solche Sachen Gedanken zu machen.
      
      Auch bei CGI würde ich nicht wirklich drauf achten ob Dateien aufgesplittet sind, weil das verglichen zu anderen aufgaben wohl absolut keine auswirkung haben wird.
      
      Ansonsten würde ich generell kein CGI heutzutage mehr empfehlen. Da es per Default langsam ist dadurch das es immer wieder neu Compiliert.
      
      Okay jetzt wirst du mir sagen das es für sehr kleine sachen wo selten jemand drauf schaut noch nutzbar ist? Wenn das der Fall ist spricht ebenfalls nichts gegen das aufsplitten in Dateien, da es einfach keine große Performance fressen wird, und wenn mal jemand drauf geht es egal ist wenn der Request 1ms länger dauert (wenn es überhaupt 1ms sind durchs Datei aufsplitten).
      
      Ansonsten muss man halt immer die Sachen im Verhältnis sehen. Es bringt nichts sinnlose Stellen zu Optimieren die auf die allgemeine ausführungszeit fast keine auswirkung haben. Und die mammutzeit die man eben bei einem webseitenrequest hat werden eher im auslesen der Daten von einer Datenbank sein, oder das ausführen des Templates sein etc.
      
      Liegt das Hauptproblem daran das Programmcode in mehrere Dateien aufgesplittet ist, wäre dann die Lösung CGI nicht mehr zu nutzen wodurch es eben nicht mehr bei jedem aufruf geladen wird. Obwohl ich mir schwer vorstellen kann das dies jemals ein Performance Problem sein wird.
      
      Ein anderes problem kann sein das das laden der Module lange dauert. Hier ist aber auch das Problem CGI, weil es ja eben nicht persitent ist, sondern immer wieder neu lädt. Oder ein Problem von Perl das es die Compilierte Form nie abspeichert (je nachdem wie man es sieht). Auch hier wäre dann aber die Lösung eben kein CGI mehr zu nutzen. Oder krücken wie "AutoLoader" zu nutzen.
      
      EDIT: zwei wörter nur ausgetauscht.
      Last edited: 2009-09-02 11:38:32 +0200 (CEST)
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
      - +3 replies
      - sid burn
        
        2009-09-02 11:46
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Ansonsten kann man die Performance bei CGI sogar durch das aufsplitten erhöhen. Hat man nämlich eine große Datei und lädt diese in seinem Programm, wird bei CGI immer alles geladen, unabhängig davon ob man bestimmte Sachen im Modul nun benötigt oder nicht.
        
        Splittet man es in mehrere Sinvolle bestandteile auf, kann man pro CGI Skript nur das laden was man auch benötigt, sprich die compilierzeit reduzieren.
        
        CGI ist z.B. ein relativ großes Modul und dauert etwas zu laden. Auch wenn du nun z.B. die Funktionen der HTML Generierung nicht benötigtest werden sie trotzdem geladen. Wären die beiden Sachen voneinander getrennt, könntest du dir z.B. sparen den Teil für die HTML generierung zu laden, was letztendlich viel effektiver ist.
        
        Deswegen gibt es ja auch abspaltungen von CGI die genau das machen. Glaube es war CGI::Lite? CGI::Simple? weiß es nun nicht genau.
        
        EDIT: Erster Satz verbessert.
        EDIT2: Typo
        EDIT3: Nochmal ein Wort ausgebessert "HTML Generierung" anstatt nur "HTML", dritter Block.
        Last edited: 2009-09-02 11:50:45 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        +2 replies
        
        pq
        
        2009-09-02 11:56
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2009-09-02T09:46:16 sid burn
        CGI ist z.B. ein relativ großes Modul und dauert etwas zu laden. Auch wenn du nun z.B. die Funktionen der HTML Generierung nicht benötigtest werden sie trotzdem geladen.
        
        naja, nicht ganz. CGI.pm arbeitet mit AUTOLOAD, und eine menge funktionen werden erst beim ersten aufruf kompiliert.
        trotzdem kann es sehr sinnvoll sein, auf CGI::Simple umzusteigen (würde ich in battie auch gern machen, jedoch kann CGI::Simple noch kein upload_hook; wenn ich rausfinde, wie das implementiert ist, werd ich versuchen, nen patch zu schreiben...)
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        umbrella
        
        2009-09-02 12:28
        
        User since
        2009-09-01
        24 Artikel
        BenutzerIn
        
        Wollte mich für die neuen Tipps bedanken. :)
        
        Viel was kann ich zu den ganzen Informationen noch nicht sagen, muss ich mir alles erstmal ansehen. Finde das aber echt große Klasse von Euch, das hier den Neulingen so eine Unterstützung geboten wird. :)
        Wer sich stets zu viel geschont hat, der kränkelt zuletzt an seiner vielen Schonung. Gelobt sei, was hart macht!
      - +3 replies
      - Taulmarill
        
        2009-09-02 15:04
        
        User since
        2004-02-19
        1750 Artikel
        BenutzerIn
        
        Grundsätzlich stimme ich dir zu, wir scheinen hier ein bisschen aneinander vorbei zu reden.
        
        Natürlich ist es Sinnvoll, Programmcode auf mehrere Dateien aufzuteilen, aber du hast in einem vorherigen Post gesagt: Aber ehrlich, über solche unsinnige Dinge sollte man nicht wirklich darüber nachdenken. Dem wollte ich widersprechen, da ich der Meinung bin, dass man da schon drüber nachdenken darf und soll. Vor allem wenn man den zu Grunde liegenden Prozess noch nicht verstanden hat.
        
        Das Thema CGI ist mir sehr unhandlich und unangenehm. Wenn alle mod_perl oder fastcgi benutzen könnten, dann würde ich auch sagen, dass CGI für die Tonne ist (die Schnittstelle zum Webserver, nicht das Modul). Die traurige Wahrheit ist aber, dass viele Webhoster für Perl nur CGI anbieten und es extra schwer machen, eigene Module zu installieren, weil einem z.B. Shellzugang verwehrt wird.
        
        Kennst du einen Webhoster, bei dem man ohne weiteres mit Catalyst, DBIx::Class, Moose u.s.w. loslegen kann, ohne einen eigenen Server oder zumindest einen vServer zu kaufen?
        $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
        
        pq
        
        2009-09-02 15:08
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        variomedia.de bietet shellzugang (ab dem webhosting.500 paket), allerdings ist es shared hosting. die (CGI)-programme laufen aber unter unter dem eigenen usernamen, also vielleicht per setuid.
        ich bin da schon ewig und hab da auch schonmal DBIx::Class installiert, geht prima.
        Last edited: 2009-09-02 15:10:04 +0200 (CEST)
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        sid burn
        
        2009-09-02 15:50
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Das Thema CGI ist mir sehr unhandlich und unangenehm. Wenn alle mod_perl oder fastcgi benutzen könnten, dann würde ich auch sagen, dass CGI für die Tonne ist (die Schnittstelle zum Webserver, nicht das Modul). Die traurige Wahrheit ist aber, dass viele Webhoster für Perl nur CGI anbieten und es extra schwer machen, eigene Module zu installieren, weil einem z.B. Shellzugang verwehrt wird.
        
        Auch wenn man einen Shared Hoster mit nur CGI hat, spricht nichts dagegen Module auf Dateien aufzusplitten. Solange es sogar PurePerl Module sind kannst du diese einfach auf deinen Rechner herunterladen/installieren und simpel einfach hochladen. "Mojo" nennt es explizit, grundsätzlich geht es aber mit jedem PurePerl Modul. Module die auf XS basieren sind natürlich schwieriger, rein theoretisch aber immer noch machbar wenn du eine eigene VM aufsetzt das dem zielsystem entspricht, zumindest 32-bit/64bit und dann in dieser die Module kompilierst.
        
        Module kannst du auch lokal installieren z.B. mit "local::lib". Rein theoretisch ist das auch ohne Shellzugriff alles Möglich. Denn wenn du ein Perl Programm ausführen kannst, kannst du ebenfalls auch alles machen, was du in einer Shell machen kannst, dafür gibt es sogar schon sogenannte Ajax Terminals.
        
        Ist ein C Compiler installiert kannst du sogar gleich auch XS Module installieren.
        
        Catalyst kannst du z.B. auch im Shared Hosting bereich installieren, hat der Apache lediglich das Modul fcgi geladen kannst du sogar FastCGI nutzen. Das neue Catalyst Buch erklärt wie es geht, allerdiengs findet sichd azu auch etwas im Cookbook:
        
        http://search.cpan.org/perldoc?Catalyst::Manual::C...
        
        Unabhängig davon finde ich den Grund "Webhoster" kein trifftiges Argument. Worum geht es denn da genau? Um den Preis? Bei Server4You bekommst du vserver für 8€ im Monat, selbst Shared Hoster sind da nicht immer billiger. Und die Investion für eine vernünftige umgebung ist da denke ich gerechtfertigt.
        
        Ansonsten ist gerade Shared Hosting per se ein graus weil dort relativ viele Leute sich die Ressourcen teilen. Selbst wenn man FastCGI nutzt würde das auf solch einen Server wohl nicht viel besser laufen. Und CGI kannst du wohl erst recht vergessen.
        
        Ich sehe kein Sinn darin für eine schlechte arbeitsumgebung zu Programmieren die per definition schon probleme hat.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

View all threads created 2009-09-02 00:33.