Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich? - baseportal Forum - Web-Anwendungen einfach, schnell, leistungsfähig!
baseportal
English - Deutsch "Es gibt keine dummen Fragen - jeder hat einmal angefangen"

 baseportal-ForumDie aktuellsten 10, 30, 50, 100 Einträge anzeigen.  

 
 Ausgewählter Eintrag: Zur Liste 
    Beitrag von Christoph Bergmann (8110 Beiträge) am Samstag, 5.Mai.2001, 17:32.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Die erste Frage mit "init" und so hab ich nicht verstanden, aber "get" ruft selbst "init" auf wenns sein muss und "init" optimiert insofern, dass es checkt ob eine DB schon initialisiert wurde und das nicht unnötig zweimal macht...

      Liste: Das ist schon ok. Mmhh, nein, also normalerweise sollten interne Funktionen schneller als selbstgebaute sein, in dem Fall hat "loop" aber aus anderen Gründen einen gewissen Overhead...

      Datum:

      $fzeit_e = "1.$mon+1.$jar";

      kann nicht funktionieren, da du das +1 innerhalb der anführungsstriche geschrieben hast, d.h. das ist für perl normaler text. richtig wäre:

      $fzeit_e = "1.".($mon+1).".$jar";

      das verhalten von baseportal bzgl. <= ist (glaub ich) in der doku beschrieben, das haengt damit zusammen, wie das datum intern gespeichert wird... ist aber "an sich" schon richtig...

      frage: warum machst Du das alles so kompliziert? was spricht dagegen, die datumsabfrage gleich ins get zu integrieren?

      get "Datum>jetzt Datum<$fzeit_e sort=Datum,Landkreis,Ort Landkreis~=$flk ... etc.", "veranstaltungen";

      while(get_next("veranstaltungen"))
      {
 ... # was du so machen willst, die if-abfrage ist dann nicht mehr notwendig...
}


    Ihre Antwort:

    Name: EMail: EMail bei Antwort? WWW:
    Titel:
    Text:

    Neuer Eintrag


 Alle Einträge zum Thema: Zur Liste 
    Beitrag von Ruben (403 Beiträge) am Freitag, 4.Mai.2001, 19:18.
    @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Hallo,
      bin eben mal am optimieren einiger "wilder" Scripte. Um nun nur noch ein loop im Template zu haben, stellt sich die Frage, wie man Fix-Variablen, die innerhalb des Loops dann runter- bzw. raufgezählt werden, mittels eines init "db" belegen kann. Muß aber unbedingt ein "gefiltertes Init" sein, da diese Vars die zweispaltige Ausgabe im loop steuern (Anfangswerte abhängig von Anzahl der gewählten Datensätze - es wird mit betreffendem Template prinzipiell nur eine Teilmenge aller DS einer DB ausgegeben)
      Hab das jetzt mit einem 
      get "Filterbedingung", "db" 
gemacht, haut auch hin. Ist das ebenso effektiv wie init oder nicht - und wenn nicht, wie kann man das dann über init machen?
Hier der Code des get:
get "sort=ort art~=$fa&konfes~=$fkon°konfes~=sons&ort~=$fort&landkreis~=$flk°landkreis~=Wei°landkreis~=Frei°landkreis~=Stol", "viskart";
Dazu kommt jetzt noch das Prob, daß ich eine Liste, die später in einem Option-Feld (zur Ortssuche)ausgegeben wird, aus einer Teilmenge der DB mittels einer anderen Filterbedingung füllen muß - hab das in nem anderen Template mittels get/get_next gemacht - bin mir nicht sicher, ob das so ok ist (ist mein Gedankengang, daß loop "langsamer" ausgeführt wird als get/get_next, weil es eine bp-interne Fkt. die mittels einer get/get_next-ähnlicher Konstruktion gebildet wird, richtig - oder ist das Blödsinn?)
Und dann ist da noch die Sache mit dem Datum, vielleicht kann mal bitte jemand zum Beitrag http://baseportal.de/cgi-bin/baseportal.pl?htx=/baseportal/forum&wcheck=1&Pos=1998 was sagen?
      CU und Danke für Tips
      Ruben

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Samstag, 5.Mai.2001, 17:32.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Die erste Frage mit "init" und so hab ich nicht verstanden, aber "get" ruft selbst "init" auf wenns sein muss und "init" optimiert insofern, dass es checkt ob eine DB schon initialisiert wurde und das nicht unnötig zweimal macht...

      Liste: Das ist schon ok. Mmhh, nein, also normalerweise sollten interne Funktionen schneller als selbstgebaute sein, in dem Fall hat "loop" aber aus anderen Gründen einen gewissen Overhead...

      Datum:

      $fzeit_e = "1.$mon+1.$jar";

      kann nicht funktionieren, da du das +1 innerhalb der anführungsstriche geschrieben hast, d.h. das ist für perl normaler text. richtig wäre:

      $fzeit_e = "1.".($mon+1).".$jar";

      das verhalten von baseportal bzgl. <= ist (glaub ich) in der doku beschrieben, das haengt damit zusammen, wie das datum intern gespeichert wird... ist aber "an sich" schon richtig...

      frage: warum machst Du das alles so kompliziert? was spricht dagegen, die datumsabfrage gleich ins get zu integrieren?

      get "Datum>jetzt Datum<$fzeit_e sort=Datum,Landkreis,Ort Landkreis~=$flk ... etc.", "veranstaltungen";

      while(get_next("veranstaltungen"))
      {
 ... # was du so machen willst, die if-abfrage ist dann nicht mehr notwendig...
}

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Samstag, 5.Mai.2001, 17:37.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Wobei Du das Datum in $fzeit_e im internen Format aufbauen müsstest, also irgendwie so:

      $fzeit_e = "20$jahr.".($mon+1);

      wenn $jahr (oder $jar?) nur 2 stellen hat, ansonsten ohne "20" vorne dran... den tag brauchst du bei dem vergleich garnicht...

     Antworten

    Beitrag von Ruben (403 Beiträge) am Samstag, 5.Mai.2001, 20:03.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Danke für die Antwort - macht mich etwas "ruhiger" bezüglich Laufzeitverhalten der Scripte.

      Zu deinen Fragen:
      so kompliziert ist der Datumsfilteraufbau, weil die Werte intern noch manipuliert werden (sollen), außerdem ist die Aufbereitung der Daten in ein extra Template ausgelagert, das dadurch (ziemlich) universell zur Manipulation von verschiedenen Zeitraumsabfragen einsetzbar ist.
      Im get als Filterbedingung eingesetzt hat die Abfrage nicht gefunzt (vielleicht hatte ich mich auch nur bei den Varnamen verschrieben), in der if-Abfrage dann gings.

      Die doppelten loops hab ich unterdessen raus, eine zweispaltige Ausgabe geht auch mit einem (verschiedene Zählvars für links und rechts, Einlesen der gesamten Ausgabe in Vars, die dann einfach an der auszugebenden Stelle eingesetzt werden - wir hatten da vor Wochen schon mal dazu gepostet ( http://baseportal.de/cgi-bin/baseportal.pl?htx=/baseportal/forum&wcheck=1&Pos=1511.5 - ist zwar etwas anders in der Syntax als du damals vorgeschlagen hattest zu nutzen, geht aber hervorragend wenn man macht $var = $var.<<EOF; - ich setz es unterdessen ein, man kann damit Script- und Ausgabebereich sehr gut trennen.
      Mit dem Einlesen von Feldwerten einer Datenbank in eine Drop-Down-Liste geht mit get/get_next ebenfalls sehr gut, krieg halt bloß noch nicht hin, daß es in ein und demselben get/get_next Konstrukt mit verschiedenen Filterbedingungen zu unterschiedlichen Ausgaben kommt (damit die gesamte DB nicht mehrmals durchlaufen werden muß - bin aber dran und werd das mal mit unterschiedlichen if-Bedingungen probieren)
      Wenn morgen das Veranstaltungskalenderscript die richtigen Ausgaben macht (Sonntag :-), dann stell ich es in die Bib, mit dem Redaktionssystem werd ich in den nächsten Wochen eh nicht fertig - Prüfungs"streß".
      So - ich bin grad von meinem festen Mädchen in den Chat eingeladen worden, und mach dann noch bissel weiter.
      CU
      Ruben

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 7.Mai.2001, 19:12.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Mmh, das mit dem Datum ist so eine Sache, an sich soll das so nicht, sein, dass Du/die Nutzer da noch extra dran schrauben müssen - mal sehen, was Dir noch gefehlt hat war ja sowas wie "bis zum nächsten Monat" oder "diese Woche" - sollte man mal irgendwann direkt einbauen...

      $var=$var.<<EOF;

      kannst Du noch in

      $var.=<<EOF;

      verkürzen ;-)

      Ob ein einmaliges Durchlaufen mit Verlagerung der Abfragen (mit "if") in den Perl-Code schneller ist als die DB mehrmals gleich mit den richtigen Kriterien abzurufen hängt ganz von den Umständen ab: Bei einer grossen Db mit sagen wir 1000 Einträgen bei der man z.B. nach 3 verschiedenen Kriterien einige wenige Datensätze (z.B. 20) abrufen will, ist es besser die DB mehrmals abzurufen...

      Wie, Du unterhältst Dich mit Deiner Freundin via Chat?
      ;-) Oder wohnt Ihr nicht in derselben Stadt?

     Antworten

    Beitrag von Ruben (403 Beiträge) am Montag, 7.Mai.2001, 20:16.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Mhm - das mit dem $var.<<EOF ging bis gestern noch nicht (oder hatte ich mich vertippt?) - jetzt grad probiert - geht. Also schnell angepaßt, wenn ich grad mal an sonem Template arbeite.

      Schau dir mal bitte das Template des Veranstaltungskalenders in der Bib an, wenn du mal Zeit haben solltest (war wohl eher n Witz, wann hast du mal Zeit seit dem du bp ins Leben gerufen hast .-),
      das hab ist soweit hingebogen, daß ein "Haupt"-get/get_next mit allen Zählern, Varbelegungen etc. die Ausgabe macht. Vorher waren 2 get_next und ein loop drin - das war nicht sogut.

      Aber ein zusätzliches get_next krieg ich nicht raus, weil da für das Füllen eines Optionfeldes mit DB-Feld-Inhalten nach anderen Filterkriterien als die Ausgabe erfolgen muß (im Bsp. alle Orte für die Events eingetragen wurden, sortiert nach Alpahbet, im aktuellen Jahr ohne Doubletten) - es ginge bestimmt in der ersten (beim get_next keine Filterung und über if dann die Filterbed. setzen - weiß aber halt nicht, was effektiver im Laufzeitverhalten ist.

      Das mit aktuelle Woche, nächste Woche, dieser Monat, nächster Monat, dieses Jahr, nächstes Jahr ist nun (für meine Begriffe) komplett gelöst - ist im Template (Bib - Templ. i_pl_wochrech) auch erklärt.

      Am Zerlegen in die einzelnen Datumbestandteile führt m.E. nach im Moment kein Weg vorbei, um Zeitfenster in nen Filter zu bekommen, außerdem geht nur so ein Rechnen bzw. eine generelle Weiterverarbeitung (Nutzung in Listen, Hashs) - die Funktion der automatischen Löschung bspw. von Datensätzen älter als 1 Monat geht auch nur mit Teilen, weil zum einen das Jahr angegeben werden muß und dann erst der Monat, sonst sind alle DS weg (ist von der Logik des bp-Datums auch klar, wenn ich sage del (Datum<_datum_Monat-1), dann löscht er alle DS, deren Monatszahl 1 kleiner als der aktuelle, gleich in welchem Jahr (und damit alle!) ist.

      Die Berechnung des Datums beim Zusammenbau ist ok - mir war der Verkettungsoperator . nicht eingefallen, danke.

      Hab aber ungeachtet dessen trotzdem Vars belegt, ist von der "Nutzungslogik" einfacher zu überblicken (oder sind zuviel Vars wieder Laufzeithemmend?)

      Wenn ich dir erzähle, daß meine Frau und ich im selben Haus wohnen und sie mit mir per Internet im Chat "kommuniziert", lachst du dich bestimmt kaputt - wir habens schon fertiggebracht, daß die ganze Family (2 Jungs Nachzucht) im Chat war, sehr zur Verwirrung der anderen Chatter - macht heidenspaß! *fg*

      Fällt mir grad ein, nen chat mit bp basteln wär wohl nicht so gut oder? müßte doch eigentlich auch funzen (fragt sich halt bloß, was der Server dazu meint oder?)
      CU
      Ruben

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 8.Mai.2001, 08:52.
    Re: @Profis - Laufzeitverkürzung von Scripten - Filterbedingung in init möglich?

      Du hast Dich wohl vertippt, muss heissen:

      $var.=<<EOF;

      also mit = (das fehlt bei Dir oben).

      Veranstaltungskalender: Doch, ich schau mal drüber, obwohl die Analyse fremder Programme ist schon sehr schwierig und langwierig ist...

      get/get_next: Naja, wie geschrieben, das hängt vom Fall ab - wieviel Einträge sind denn so in einer Datenbank bei Dir?

      Ja, mit dem Datum ist so eine Geschichte, es ist wirklich sehr kompliziert (aus kulturgeschichtlichen Gründen, die Mannschaft der Enterprise hat da bestimmt weniger Probleme ;-) ). Ein paar Sachen sollten schon noch direkt in baseportal integriert sein, wie "nächste Woche", "nächsten Monat" etc. Naja, alles was man halt braucht...

      Nein, (normale) Vars kann man schon ne sehr grosse Menge haben, bevor man sich da Gedanken machen muss... Hängt natürlich auch davon ab, wie gross der Inhalt ist, dann gibts aber halt normale Speicherplatzprobleme...

      Na, da scheint ihr aber ein grosses Haus zu haben... Aber wenns Spass macht ;-) Mmh, also nen richtigen Chat zu basteln ist schwierig, weil man keine Sockets aufmachen darf (geht in HTML ja sowieso nicht), also da ist Java doch um einiges geeigneter. Abgesehen davon gibts ja schon ca. 1 Mio. mehr oder weniger gute Chats im Quellcode (z.B. hier: http://java.seite.net ;-) )

     Antworten


     
 Liste der Einträge von 62551 bis 62701:Einklappen Zur Eingabe 
Neueste Einträge << 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | Neuere Einträge < Zur Eingabe  > Ältere Einträge | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 >> Älteste Einträge

Zurück zur Homepage

© baseportal.de. Alle Rechte vorbehalten. Nutzungsbedingungen



powered in 0.08s by baseportal.de
Erstellen Sie Ihre eigene Web-Datenbank - kostenlos!