Closed csalzmann closed 3 years ago
Danke :))
Produzieren wir denn so viele Fehler mit der FloraDB, dass das Cache leeren immer nützt? Weil es nützt ja wirklich
Ein paar Versuche, das zu beantworten:
Müsstest Du dann nicht unseren Cache anschauen, um die Fehler zu finden?
Gute Frage aber das ist nicht möglich. Ich muss das selber provozieren können, um das Problem besser zu verstehen.
Zur Info: Performance ist ein wichtiges Anliegen. Daher arbeite ich im Hintergrund an weiteren Anpassungen, welche sie erhöhen sollten. Es geht darum, die Abfragen für den verwendeten Cache zu optimieren.
Ist aber viel Arbeit und daher wird es je nach anderen Projekten ein paar Tage bis Wochen dauern, bis das live geschaltet wird.
Heute ist alles recht verzögert. Rechte Mausklick-Menüs kommen spät und/oder bleiben dann hängen (hab ich auch schon mal gemeldet)
Es ist ein bisschen unspezifisch, aber generell hat man das Gefühl, es wird wohl sehr viel gerechnet im Hintergrund. Ich wollte es Dir einfach melden, vielleicht siehst Du ja einen Zusammenhang mit Deinen Arbeiten.
Generell scheint mir langsam, es hätte mit der Suche& Filter zu tun, resp. seit Du diese ausgebaut hast. Morgen sitzen wir ja zusammen:).
Ich fände es interessant von Dir zu hören, was Du für welche Funktionen als "normale" Wartezeit betrachtest.
Ab sofort laden Populationen und nicht beurteilte Beobachtungen einen Schritt später: Erst, wenn man ihren Ordner öffnet. Bisher wurden sie schon geladen, wenn der AP geöffnet wurde.
Grund: Die teilweise lange Dauer verkürzen, die bisher verstrich, wenn man den AP-Ordner öffnete, bis alle benötigten Daten geladen waren.
Das funktioniert nur, wenn auf Populationen/Beobachtungen kein Filter gesetzt wurde. Wenn ein Filter gesetzt wurde, laden sie wie bisher, wenn der AP-Ordner geöffnet wird. Grund: Damit die Anzahl Pop/Beob gefiltert werden kann.
Ich habe soeben ein Update live geschaltet, das bei den Formular-Filtern das eigentliche Filtern 100% an die Abfragen auslagert. Damit muss die Anwendung viel weniger selber rechnen.
Ausserdem zeigt das Filter-Formular nun auch die Anzahlen (gefiltert und total) des aktiven AP's an (bisher nur des ganzen Projekts).
Ich würde das gerne auch für den Strukturbaum-Filter machen. Leider bezieht er sich auf den Label, das heisst auf den Inhalt zweier vereinigter Felder. Daher geht das leider nicht ohne Nachteile. Beispiel: Aktualisiert man eines der beiden Felder würde der Label im Strukturbaum nicht sofort aktualisiert.
Aber ich denk noch mehr darüber nach.
Ich könnte den Strukturbaum-Filter ähnlich dem Formular-Filter leistungsmässig optimieren, wenn wir bereit sind, einen Nachteil zu akzeptieren. Weil Tempo ein Problem ist, tendiere ich dazu, das zu machen. Der Nachteil ist:
Heute kann man bei Populationen im Filterfeld die Nummer und den Namen der Population kombiniert filtern. Man kann z.B. 1: Wingert
eingeben und es findet die Population mit Nr. 1
und dem Namen, der mit Wingert
beginnt.
Künftig könnte man die Nummer und den Namen nicht mehr kombinieren. Man kann als 1
eingeben oder Wingert
. Gibt man 1: Wingert
ein, findet er nichts.
Das trifft überall zu, wo im Label (= dem Namen im Strukturbaum) der Inhalt mehrerer Felder kombiniert wird. Beispiele: EK, EFK, Berichte, Massnahmen-Berichte.
Ich könnte die Anwendung so machen, dass sie sofort eine Meldung anzeigt, welche besagt, dass die Kombination beider Felder nicht gefiltert werden kann, wenn jemand den Doppelpunkt (:
) im Filterfeld eingibt.
Bitte sagt mir möglichst rasch, wenn euch dieser Nachteil problematisch erscheint. Ansonsten werde ich das umsetzen. Denn mir scheint, der Strukturbaum-Filter bringt die CPU (den Prozessor) ins Schwitzen.
Hm. Ich kann sogar die Eingabe am Doppelpunkt trennen und den Filter auf die beiden Felder verteilen. Sollte funktionieren. Dann wäre nicht einmal ein Nachteil damit verbunden :-)
Ich glaube, ich habe herausgefunden, wie die Performance auf elegante Weise stark gesteigert werden kann :-)
Lieber Alex
Das wäre natürlich super!!
Herzliche Grüsse
Karin Marti Dr.sc.nat.ETH topos Marti & Müller AG Idastr. 24 8003 Zürich Tel. 044 451 52 55 marti@toposmm.ch
Am 31.03.2019 um 00:31 schrieb Alexander Gabriel notifications@github.com:
Ich glaube, ich habe herausgefunden, wie die Performance auf elegante Weise stark gesteigert werden kann :-)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/barbalex/apf2/issues/200#issuecomment-478298364, or mute the thread https://github.com/notifications/unsubscribe-auth/AJuIH_Q_suNuILM1MFP2dlnqLMQDj6DLks5vb_O3gaJpZM4Y7xnv.
Es wird definitiv schneller. Ist aber viel Arbeit, daher werden die Fortschritte nach und nach live geschaltet.
Merkt ihr etwas?
Ich hab das Gefühl, es hat viel gebracht. Bin aber gespannt, wie ihr das erlebt. Bin immer noch daran, weitere Verbesserungen vorzunehmen, aber ein grosser Teil ist umgesetzt.
Habe heute etwas mit der DB gearbeitet (aber nicht so intensiv und nichts schwieriges). Fand sie arbeitet gut, wäre mir also nicht aufgefallen, dass es lange Wartezeiten etc. gegeben hätte ;-). Werde es weiter beobachten. LG
Super. Bitte um weitere Rückmeldungen, sobald ihr etwas melden könnt.
Ich habe nochmals etwas gefunden, was die Arbeit, welche die Anwendung leisten muss, stark reduziert :-)
Werde es nach und nach einführen.
O.k., ist jetzt umgesetzt. Und ich glaube, es klappt :-)
Ich wollte einfach mal ein positives Feedback geben. Ich finde, die Performance ist wirklich gut jetzt. Habe zwar noch nicht mit den Karten gearbeitet, da kann ich noch keine Aussage machen, was dann passiert. Aber so bin ich sehr zufrieden. Danke! Deine Arbeit hat sich also sehr gelohnt!
Hoi Alex Ich hatte jetzt schon mehrmals das Problem, dass wenn ich eine neue Teilpopulation (in einer bestehenden Population) erstellt habe, mehrere Anläufe brauche, bis die FloraDB die eingegebene Nummer und den Flurnamen "schluckt". Ich kann sie zwar problemlos eingegeben, aber sie werden nicht im Strukturbaum angezeigt. Und solang sie im Strukturbaum nicht angezeigt werden, löscht es die eingegeben Namen einfach wieder, wenn ich auf eine andere Schaltfläche drücke. Vielleicht könntest du dir das mal anschauen? Aktuelles Beispiel: Himantoglossum hircinum, Pop. 137, TPop 3 (sollte es werden). Vielen Dank!
Hoi Rebecca
Ja, da gibt es einen schwerwiegenden Fehler, siehe https://github.com/barbalex/apf2/issues/373
Ich habe zu langsam reagiert, weil:
Danke für die Meldung.
Künftig bitte:
LG, Alex
Hoi Alex
Ja, war mir eben nicht ganz sicher ob es ein Fehler ist oder ob einfach die Performance wieder etwas schwächelt. Werde es mir merken und in Zukunft lieber einen Issue zu viel erstellen.
Danke und liebe Grüsse Rebecca
Oh, richtig, ich hatte schon vergessen, wie das mal war und dass man das durchaus verwechseln konnte!
Ich schliesse diesen Issue, weil er seit 1.5 Jahren gelöst zu sein scheint
Können wir diesen Issue offen lassen? Ist ja nach wie vor ein Problem. Die Datenbank ist so toll, und wir können so viele neue Sachen machen. Aber dass sie so langsam ist, ist einfach so schade. Da macht es weniger Freude, damit zu arbeiten. Wir müssen dran bleiben!