BerndK: Geschwindigkeit optimieren!

Hi,

ich hab ein Problem mit der Geschwindigkeit in JavaScript!

Ich habe ein Mehrdim. Array (3 Dim). Aktuell umfasst das ca. 7500 Zeilen. (Es kann auch mehr als 15000 Zeilen umfassen)

Aufbau sieht so aus:
average = new Array();
average['06008120'] = new Array();
average['06008120']['temp1'] = new Array();
average['06008120']['temp2'] = new Array();
average['06008120']['temp1']['test1']='-';
average['06008120']['temp2']['test1']='0';
average['06008120']['temp1']['test2']='1sec';
average['06008120']['temp2']['test2']='1sec';
average['06008120']['temp1']['test3']='81.65';
average['06008120']['temp1']['test4']='96.28';
average['06008120']['temp1']['test5']='122.78';
average['06008120']['temp2']['test3']='81.65';
average['06008120']['temp2']['test4']='96.28';
average['06008120']['temp2']['test5']='122.78';
average['06008120']['temp1']['test6']='0';
average['06008120']['temp2']['test6']='0';

average['06008121'] = new Array();
average['06008121']['temp1'] = new Array();
average['06008121']['temp2'] = new Array();
average['06008121']['temp1']['test1']='-';
average['06008121']['temp2']['test1']='0';
average['06008121']['temp1']['test2']='1sec';
average['06008121']['temp2']['test2']='1sec';
average['06008121']['temp1']['test3']='81.65';
average['06008121']['temp1']['test4']='96.28';
average['06008121']['temp1']['test5']='122.78';
average['06008121']['temp2']['test3']='81.65';
average['06008121']['temp2']['test4']='96.28';
average['06008121']['temp2']['test5']='122.78';
average['06008121']['temp1']['test6']='0';
average['06008121']['temp2']['test6']='0';

Mit Hilfe dieses Arrays  erstelle ich dynamisch Selectboxeinträge. Leider braucht es bei den aktuellen 7500 Zeilen ca. 10 Sekunden, bis die Selectboxen fertig gefüllt sind.

Kann ich da noch was an Geschwindigkeit rausholen? Wenn ja, welche Tricks gibts dafür?

Vielen Dank

  1. Hi, eigentlich hört sich das nach einer Aufgabe an, die man besser auf dem Server via PHP löst und nicht auf dem Client Rechner... wozu brauchst Du das ?

    1. Hi,

      Hi, eigentlich hört sich das nach einer Aufgabe an, die man besser auf dem Server via PHP löst und nicht auf dem Client Rechner... wozu brauchst Du das ?

      ich vermute, dass die SELECT-Boxen beim Client gefuellt werden, damit die uebergebene Datenmenge nicht zu gross ist. Stichwort: Redundanzvermeidung

      Gruss,
      Lude

      1. Hi, eigentlich hört sich das nach einer Aufgabe an, die man besser auf dem Server via PHP löst und nicht auf dem Client Rechner... wozu brauchst Du das ?

        ich vermute, dass die SELECT-Boxen beim Client gefuellt werden, damit die uebergebene Datenmenge nicht zu gross ist. Stichwort: Redundanzvermeidung

        Das klingt unlogisch.
        Er baut mit einem riesigen JS Array Select boxen zusammen. Das sieht wirklich so als ob man das schneller auf dem Server erledigt und dann nur die fertigen Formulare zum Client schicken und damit ist die übergebene eher Datenmenge kleiner als wie es jetzt ist.

        Aber es gibt sicher eine andere sinvollere Erklärung.

        Struppi.

        1. Hi,

          ich vermute, dass die SELECT-Boxen beim Client gefuellt werden, damit die uebergebene Datenmenge nicht zu gross ist. Stichwort: Redundanzvermeidung

          Das klingt unlogisch. [...]

          ich habe dasselbe Problem. Beispielsweise muss ich SELECT-Elemente anbieten, die hunderte von Orten halten, oder tausende von Konten.

          Dann entsteht das Dilemma, wenn man eine groessere Datensatzmenge (mit o.g. SELECT-Elementen) zur Ansicht bringen moechte.
          1.) sehr grosse Datenmengen (>10MB) mit redundanten Daten gehen an den Browser
          2.) (alternativ) werden die SELECT-Elemente mit Daten aus einem JS-Array gefuellt, was in der Tat merkweurdig lange dauert (jedenfalls bei mir, dem absoluten JavaScript-Experten ;-)

          Gruss,
          Lude

          1. Hi Lude,

            Beispielsweise muss ich SELECT-Elemente anbieten, die hunderte von Orten halten, oder tausende von Konten.

            1.) sehr grosse Datenmengen (>10MB) mit redundanten Daten gehen an den Browser

            diese Vorgangsweise ist unbrauchbar und unnötig.

            2.) (alternativ) werden die SELECT-Elemente mit Daten aus einem JS-Array gefuellt, was in der Tat merkweurdig lange dauert (jedenfalls bei mir, dem absoluten JavaScript-Experten ;-)

            Kein Wunder bei der Menge. Es wäre wesentlich geschickter, zunächst eine grobe Auswahl zuzulassen, um mit deren Ergebnis auf Folgeseiten (oder beispielsweise in Iframes) weitere Möglichkeiten bereitzustellen.

            Grüße,
             Roland

            1. Hi,

              1.) sehr grosse Datenmengen (>10MB) mit redundanten Daten gehen an den Browser

              diese Vorgangsweise ist unbrauchbar und unnötig.

              OK.

              2.) (alternativ) werden die SELECT-Elemente mit Daten aus einem JS-Array gefuellt, was in der Tat merkweurdig lange dauert (jedenfalls bei mir, dem absoluten JavaScript-Experten ;-)

              Kein Wunder bei der Menge. Es wäre wesentlich geschickter, zunächst eine grobe Auswahl zuzulassen, um mit deren Ergebnis auf Folgeseiten (oder beispielsweise in Iframes) weitere Möglichkeiten bereitzustellen.

              Hmmm. Du kennst vielleicht die Data-Grids. Meiner Anforderungslage zufolge sind diese "mit HTML&Co" nachzubilden. Ich habe also ein Grid mit z.B. 50 Datensaetzen in einer Trefferliste. Jeder Satz verweist auf Orte (300 Datensaetze) und Konten (2000 Datensaetze).

              Dein Vorschlag zielt also darauf bei der ersten Auswahl des Nutzers (z.B. 1.Buchstaben) zum Server zu gehen und ein SELECT-Element wieder neu zu fuellen? - Gut, das geht, aber ist das besser als Variante 2?

              kleine Frage noch: Mit einem XML-interpretierenden Browser wuerde man doch einen komplexen Typ definieren ("Orte") und dann die SELECT-Elemente diesem Typ einmalig zuordnen? Wenn das ginge, waere das doch "zivilisierter"?

              Gruss,
              Lude

              1. Hi Lude,

                Meiner Anforderungslage zufolge sind diese "mit HTML&Co" nachzubilden.

                ich lese nichts, das serverseitiger Unterstützung ausschließt.

                Ich habe also ein Grid mit z.B. 50 Datensaetzen in einer Trefferliste. Jeder Satz verweist auf Orte (300 Datensaetze) und Konten (2000 Datensaetze).

                Muss der Client das bereits bei der ersten Anforderung wissen?

                Dein Vorschlag zielt also darauf bei der ersten Auswahl des Nutzers (z.B. 1.Buchstaben) zum Server zu gehen

                Nein. Um bei deinem Beispiel zu bleiben:

                Zuerst wird der erste Datensatz ausgewählt. Welcher das war, wertest du serverseitig aus und schickst folglich nur mehr die 300 (bzw. 2000?) möglichen Datensätze zur weiteren Auswahl. Lässt sich in deine Daten keine Hierarchie bringen?

                Gut, das geht, aber ist das besser als Variante 2?

                Wenn es für dich brauchbar ist, ja.

                kleine Frage noch: Mit einem XML-interpretierenden Browser wuerde man doch einen komplexen Typ definieren ("Orte") und dann die SELECT-Elemente diesem Typ einmalig zuordnen? Wenn das ginge, waere das doch "zivilisierter"?

                Ich verstehe nicht ganz, was du damit meinst.

                Gegenfrage: Wieviele XML-interpretierenden Browser kennst du?

                Grüße,
                 Roland

                1. Hi,

                  Ich habe also ein Grid mit z.B. 50 Datensaetzen in einer Trefferliste. Jeder Satz verweist auf Orte (300 Datensaetze) und Konten (2000 Datensaetze).

                  Muss der Client das bereits bei der ersten Anforderung wissen?

                  Nein.

                  Dein Vorschlag zielt also darauf bei der ersten Auswahl des Nutzers (z.B. 1.Buchstaben) zum Server zu gehen

                  Nein. Um bei deinem Beispiel zu bleiben:

                  Zuerst wird der erste Datensatz ausgewählt. Welcher das war, wertest du serverseitig aus und schickst folglich nur mehr die 300 (bzw. 2000?) möglichen Datensätze zur weiteren Auswahl. Lässt sich in deine Daten keine Hierarchie bringen?

                  Die Daten fuer die SELECT-Elemente (z.B. Orte, Konten) sind schwach strukturiert (soz. natuerlich strukturiert; Kategorisierung nur nach erster Ziffer oder erstem Buchstaben moeglich) und eine Strukturierung wird nicht ins Auge gefasst.

                  Gut, das geht, aber ist das besser als Variante 2?

                  Wenn es für dich brauchbar ist, ja.

                  Ich haette gerne fuer meine Zwecke eine funktionierende Variante 2, aber moeglicherweise bringt JS das nicht?

                  kleine Frage noch: Mit einem XML-interpretierenden Browser wuerde man doch einen komplexen Typ definieren ("Orte") und dann die SELECT-Elemente diesem Typ einmalig zuordnen? Wenn das ginge, waere das doch "zivilisierter"?

                  Ich verstehe nicht ganz, was du damit meinst.

                  Gegenfrage: Wieviele XML-interpretierenden Browser kennst du?

                  Nun, die uebertragene Datenstruktur fuer "mein Grid" ist eine Datensatzmenge, deren Datensaetze wiederum selbst Datensatzmengen beinhalten darf. Ich nenne diese Struktur einmal Dokument (kann man gerne auch RDB nennen). Diese laesst sich prima mit beispielsweise XML-Schema schematisieren und ein diesem Schema entsprechendes Dokument koennte man dem Broser zusenden, der dann moeglicherweise intern noch eine kleine Transformation durchfuehrt und die Daten dann ausgibt. Ich weiss es nicht, aber kann der IE das?

                  Gruss,
                  Lude

                  1. Hi Lude,

                    Kategorisierung nur nach erster Ziffer oder erstem Buchstaben moeglich) und eine Strukturierung wird nicht ins Auge gefasst.

                    das ist doch bereits eine Struktur, aufgrund der du die Datenmenge im schlechtesten Fall auf ein Zehntel reduzieren kannst, bei Buchstaben je nach Häufigkeit noch weiter.

                    Nun, die uebertragene Datenstruktur fuer "mein Grid" ist eine Datensatzmenge, deren Datensaetze wiederum selbst Datensatzmengen beinhalten darf.

                    Ich würde die Menge so früh wie möglich teilen, siehe oben.

                    Ich nenne diese Struktur einmal Dokument (kann man gerne auch RDB nennen). Diese laesst sich prima mit beispielsweise XML-Schema schematisieren und ein diesem Schema entsprechendes Dokument koennte man dem Broser zusenden, der dann moeglicherweise intern noch eine kleine Transformation durchfuehrt und die Daten dann ausgibt.

                    Dafür müsstest du aber wieder zuerst alle Daten an den Browser schicken.

                    Ich weiss es nicht, aber kann der IE das?

                    Keine Ahnung. Ist die Anwendung für ein homogenes Intranet bestimmt?

                    Grüße,
                     Roland

                    1. Hi,

                      Ich weiss es nicht, aber kann der IE das?

                      Keine Ahnung. Ist die Anwendung für ein homogenes Intranet bestimmt?

                      wer weiss ob und welche Browser XML-Daten zur Ansicht (nicht als "XML-Treeview", sondern ganz "normal") bringen koennen? (Und wie machen die's?)

                      Gruss,
                      Lude

                      1. Hallo Lude,

                        wer weiss ob und welche Browser XML-Daten zur Ansicht (nicht als "XML-Treeview", sondern ganz "normal") bringen koennen? (Und wie machen die's?)

                        IE ab 5.5 und Mozilla. Wie es geht, schaue dazu mal im SELFHTML-Kapitel XML Abschnitt XSL nach.

                        Viele Grüße

                        Antje

      2. Moin!

        ich vermute, dass die SELECT-Boxen beim Client gefuellt werden, damit die uebergebene Datenmenge nicht zu gross ist. Stichwort: Redundanzvermeidung

        *grrrr*

        dem steht:

        Mit Hilfe dieses Arrays  erstelle ich dynamisch Selectboxeinträge. Leider braucht es bei den aktuellen 7500 Zeilen ca. 10 Sekunden, bis die Selectboxen fertig gefüllt sind.

        ... eindeutig entgegen.
        15.000 Zeilen a 40 Zeichen = 600.000 Byte, die zudem erstmal übertragen werden müssen. Ich vermute auch, daß Javascript einfach nicht dafür gestrickt ist um als Datenbank zu arbeiten. Auch ich empfehle hier die Verwendung serverseitigen Scriptings und einer Datenbank.

        MFFG (Mit freundlich- friedfertigem Grinsen)

        fastix®

        --
        Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch  für seriöse Agenturen.
        1. Hi,

          ich vermute, dass die SELECT-Boxen beim Client gefuellt werden, damit die uebergebene Datenmenge nicht zu gross ist. Stichwort: Redundanzvermeidung

          *grrrr*

          dem steht:

          Mit Hilfe dieses Arrays  erstelle ich dynamisch Selectboxeinträge. Leider braucht es bei den aktuellen 7500 Zeilen ca. 10 Sekunden, bis die Selectboxen fertig gefüllt sind.
          ... eindeutig entgegen.

          soso. [pref:t=67794&m=388111]

          Gruss,
          Lude

          PS: Was heisst eiegentlich '*grrrr*' ?

  2. Aufbau sieht so aus:
    average = new Array();
    average['06008120'] = new Array();
    average['06008120']['temp1'] = new Array();
    average['06008120']['temp2'] = new Array();

    Das sind übrigens keine Arrays, sondern Objekte.

    Du solltest diese auch so deklarieren, damit du nicht den Fehler machst auf Eigenschaften zugreifen zu wollen die es hier nicht mehr gibt (z.b. length)

    Also so:
    average = new Object();
    average['06008120'] = new Object();
    average['06008120']['temp1'] = new Object();
    average['06008120']['temp2'] = new Object();

    Mit Hilfe dieses Arrays  erstelle ich dynamisch Selectboxeinträge. Leider braucht es bei den aktuellen 7500 Zeilen ca. 10 Sekunden, bis die Selectboxen fertig gefüllt sind.

    Kann ich da noch was an Geschwindigkeit rausholen? Wenn ja, welche Tricks gibts dafür?

    Keine Ahnung. Dauert das initialisieren der Objekte so lange oder wo ist der Flaschenhals?`

    Evtl. kannst du etwas heraus holen wenn du mit richtigen Objekten arbeitest, also in deinem Falle in etwa so (mir ist der Aufbau nicht 100% klar):

    function Average(nummer)
    {
        this.temp1 = new Object();
        this.temp2 = new Object();
        this.nummer = nummer;
    }
    Average.prototype.setTest = function(nummer, wert1, wert2)
    {
        this.temp1['test' + nummer] = wert1;
        this.temp2['test' + nummer] = typeof wert2 != 'undefined' ? wert2 : wert2;
    }

    average = new Average('06008120')
    average.setTest(1, '-', '0')
    average.setTest(2, '1sec')
    average.setTest(3, '81.65')
    average.setTest(4, '96.28')
    average.setTest(5, '122.78')
    average.setTest(6, '0')

    Übrigens sind Eigenschaften mit dem Namen 'tmp1' oder 'test' nicht besonderlich  lesbar und es ist völlig unklar was die machen sollen. Du solltest ihnen Namen geben, die Aussagen was da passieren soll.

    Struppi.

  3. Hallo Bernd,

    ich hab ein Problem mit der Geschwindigkeit in JavaScript!

    Ich habe ein Mehrdim. Array (3 Dim). Aktuell umfasst das ca. 7500 Zeilen. (Es kann auch mehr als 15000 Zeilen umfassen)

    Mit Hilfe dieses Arrays  erstelle ich dynamisch Selectboxeinträge. Leider braucht es bei den aktuellen 7500 Zeilen ca. 10 Sekunden, bis die Selectboxen fertig gefüllt sind.

    Kann ich da noch was an Geschwindigkeit rausholen? Wenn ja, welche Tricks gibts dafür?

    Das ist ein Thema was mich wirklich mal brennend interessieren würde. Wenn du willst, dann kannst du mir mal deine Testdaten etc. zusenden und ich würde mal ausprobieren, was sich da optimieren läßt.

    Viele Grüße

    Antje

  4. Hallo Bernd,

    ich hab ein Problem mit der Geschwindigkeit in JavaScript!

    nicht nur du...

    Kann ich da noch was an Geschwindigkeit rausholen?

    Ich glaube nicht. Das Problem scheint mir das schreiben mit JS zu sein. Ich habe schon mehrere Seiten mit JS gebastelt, die komplett oder teilweise mit JS geschrieben werden und immer dann wird es langsam. Die Idee auf diese Weise Zeit zu sparen, indem man weniger Daten überträgt trügt gewaltig.

    Gruß, Andreas