Datumsberechnungen

  • Datumsberechnungen

    Hallo zusammen,

    ich plane eine App in welcher unter anderem Termine vergeben werden, inklusive Wiederholungen in Intervallen usw.! Mich plagt derzeit die Performance und habe deshalb auf unterschiedlichen Wegen geprüft, wo da die Zeit verloren geht und stellte fest, dass am meisten Zeit bei den Datumsberechnungen drauf geht.

    Für eine Berechnung bzw. Prüfung ob in diesem Monat ein eingetragener Termin stattfindet oder nicht benötige ich eine knappe 10tel sec; bei 50 solcher Termine bin ich bei knapp 5 sec!!!

    Da ich nun mal eine "fluffige" App haben möchte frage ich mich ob ich die falschen Funktionen verwende.

    Derzeit benutze ich die von NSDateComponents um beispielsweise mit Aditionen bezogen auf einzelne Entities wie Monat oder Tag eingehen zu können.

    In der Doku steht dann auch so ein netter Satz: "Note that some computations can take a relatively long time"! X(

    Meine Frage nun: Gibt es performantere Funktionen; möglicherweise mächtigere Funktionen, welche mir anhand einer Wiederholdefinition eines Datums prüfen, ob ein sich ergebendes Datum in einem gegebenen Bereich liegt. ?(

    Hilfe!!!!!

    Für Tipps, Erfahrungswerte oder andere Ansätze wäre ich sehr dankbar!
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • naja, ich würd mir das ganz einfach machen:

    zuerst die 2 NSTimeIntervals holen zwischen welchen du die termine haben willst.

    dann gehst du alle termine durch und schaust ob die in dem bereich liegen. wenn sie wiederkehrend sind, dann addierst du den offset so lange hinzu und überprüfst bis du im range bist oder drüber.

    das ganze sind nur simple additionen von doubles also sollte das wahnsinnig schnell laufen!

  • Also letztlich ist dieser Teil der App wie ein Kalender zu verstehen!

    Code hab ich gerade nicht zur Hand!

    Die Daten sind in einer Datenbank. Dort kann ich Vorselektionen machen, also Daten direkt für einen Zeitraum eingrenzen. Offen bleiben aber Einträge welche ein "offenes" Ende haben, somit erstmal zeitlich immer zu beachten sind.
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Ja das mit den NSTimeIntervals klingt gut, reine doubles ...

    Dann muss ich mir nur mal Gedanken um die komplexeren Definitionen von Wiederholungen machen, Beispiel: an jedem zweiten Di alle drei Monate ?( oder nur Arbeitstage, da muss ich schon wieder Wochentage prüfen und die gehen derzeit nur mit der NSDateComponents-Sache!
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Original von contact
    Also letztlich ist dieser Teil der App wie ein Kalender zu verstehen!

    Code hab ich gerade nicht zur Hand!

    Die Daten sind in einer Datenbank. Dort kann ich Vorselektionen machen, also Daten direkt für einen Zeitraum eingrenzen. Offen bleiben aber Einträge welche ein "offenes" Ende haben, somit erstmal zeitlich immer zu beachten sind.


    da passt meine lösung perfekt.

    es kann sogar auch schneller sein wenn du dir alle daten liefern lässt und mit der methode auswertest als sie vom DB-system vorfiltern zu lassen (kommt aber immer drauf an wie die daten gespeichert sind, ob auf dem selben gerät oder irgendwo im iNet etc)

  • Original von contact
    Ja das mit den NSTimeIntervals klingt gut, reine doubles ...

    Dann muss ich mir nur mal Gedanken um die komplexeren Definitionen von Wiederholungen machen, Beispiel: an jedem zweiten Di alle drei Monate ?( oder nur Arbeitstage, da muss ich schon wieder Wochentage prüfen und die gehen derzeit nur mit der NSDateComponents-Sache!


    gibts aufm iPhone kein NSCalendarDate?

    btw: mit entsprechendem code-aufwand kannst du das alles BERECHNEN ;)

  • Ich denke ich würde dazu eine SQLite Datenbank benutzen. Die Wiederholungen würde ich als Einzelevents einfügen, aber untereinander verlinken und in der GUI entsprechend behandeln. Das verlangt einiges an Code-Arbeit, dafür ist die Suche, ob ein Termin frei ist, ein einfaches WHERE statement mit zwei Bedingungen. :)
    Widgetschmie.de • Life is too short for gadgets

  • Zitat:
    “Legacy API: NSCalendarDate” provides information about the class that represents a Gregorian calendar, NSCalendarDate. This class does not exist in iPhone OS and is deprecated in Mac OS X. All of the capabilities of NSCalendarDate are duplicated by other, recommended classes, as described in the other articles of this document.


    X(
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Original von Pascal
    Ich denke ich würde dazu eine SQLite Datenbank benutzen. Die Wiederholungen würde ich als Einzelevents einfügen, aber untereinander verlinken und in der GUI entsprechend behandeln. Das verlangt einiges an Code-Arbeit, dafür ist die Suche, ob ein Termin frei ist, ein einfaches WHERE statement mit zwei Bedingungen. :)



    Da hab ich nur Angst, dass ich mir die Datenbank schnell sehr voll mache, wobei sich da jetzt für mich die Frage stellt: Was wäre denn auf dem iPhone jetzt voll, im Sinne von Performance-Problemen. Ich denke, dass ab einer bestimmten Größe andere Probleme auftreten, aber abschätzen bzw. durchrechnen muss ich dass mal!!! Auch ein Gedanke!

    Jedoch muss ich mir da was für offene Termine einfallen lassen! Bis wohin packe ich die in die Datenbank, was passiert wenn einer ein Monat in weiter Zukunft aufruft???
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Mein Vorschlag rührt daher, dass ich ein Event-Management-System schon in mehreren Web-Basierten Datenbanken realisiert haben und die seit Jahren gut laufen. Allerdings habe ich keine sich automatisch wiederholenden Events drin. "Alte" Events kannst du ja nach x Monaten in eine andere Tabelle verschieben, verbessert eventuell die Performance.

    Events wiederholen sich ja meistens nicht für ewig und du bietest wahrscheinlich die eine oder andere Art der Terminierung an; die einfachste Lösung wäre wohl die maximale Wiederholungszeit auf z.B. 2 Jahre zu begrenzen.
    Oder aber du schreibst wiederkehrende Events nur einmal ein (ausser natürlich sie beinhalten Änderungen) und beim Check für freie Termine vergleichst du bei nicht-wiederkehrenden Events weiterhin Start- und Schlusstimestamp, für die Wiederkehrenden prüfst du erst, ob das End-Datum in der Vergangenheit liegt und wenn nicht berechnest du, basierend auf dem Interval, ob ein Konflikt vorliegen wird.
    Ich schätze dass so eine Abfrage als SQL Statement doch sehr schnell ablaufen kann, da bei der Intervall-Berechnung nur jene Events berücksichtigt werden müssen, welche auch wirklich in Frage kommen könnten.
    Widgetschmie.de • Life is too short for gadgets

  • Original von Pascal
    Mein Vorschlag rührt daher, dass ich ein Event-Management-System schon in mehreren Web-Basierten Datenbanken realisiert haben und die seit Jahren gut laufen. Allerdings habe ich keine sich automatisch wiederholenden Events drin. "Alte" Events kannst du ja nach x Monaten in eine andere Tabelle verschieben, verbessert eventuell die Performance.

    Events wiederholen sich ja meistens nicht für ewig und du bietest wahrscheinlich die eine oder andere Art der Terminierung an; die einfachste Lösung wäre wohl die maximale Wiederholungszeit auf z.B. 2 Jahre zu begrenzen.
    Oder aber du schreibst wiederkehrende Events nur einmal ein (ausser natürlich sie beinhalten Änderungen) und beim Check für freie Termine vergleichst du bei nicht-wiederkehrenden Events weiterhin Start- und Schlusstimestamp, für die Wiederkehrenden prüfst du erst, ob das End-Datum in der Vergangenheit liegt und wenn nicht berechnest du, basierend auf dem Interval, ob ein Konflikt vorliegen wird.
    Ich schätze dass so eine Abfrage als SQL Statement doch sehr schnell ablaufen kann, da bei der Intervall-Berechnung nur jene Events berücksichtigt werden müssen, welche auch wirklich in Frage kommen könnten.


    dann ist mein geburtstag also nur 2 jahre lang drin?

  • Original von gritsch
    dann ist mein geburtstag also nur 2 jahre lang drin?

    Frag mich in 2 Jahren nochmal und wir werden sehen wer recht hatte. :D :D

    Nein, klar, deshalb sagte ich "einfachste Lösung wäre".
    Widgetschmie.de • Life is too short for gadgets

  • Original von Pascal
    Sauberste Lösung ist wohl immer etwas objektiv, aber ich persönlich würde als sauberste Lösung meinen zweiten Vorschlag wählen. Sicher schnell und - ich liebe Datenbanken. :evil:


    der sauberste weg ist das nicht weil du nicht bis in die unendlichkeit daten reinballern kannst. Also woher weist du wie oft bzw wie lange sich ein wiederkehrender termin wieder holen soll?

  • Also ich werde mal beides testen; die Berechnung mal nur über elementare Datentypen und wie ich das mit den Werktagen hinbekomme sehe ich dann; letztlich unterliegt alles einer Logik.

    Das mit der Datenbanklösung werde ich mal genauer unter die Lupe nehmen; möglicherweise bleibt alles überschaubar und man kann einem Kunden nach automatisch immer mal wieder anbieten, die Wiederholsachen zu "shiften", also aus der Vergangenheit nach vorn bringen; berechnet lägen die Termine ja in der DB. Die Zukünftigen Sachen müsste ich "heimlich nachrechnen" ... grübel grübel ...
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Original von gritsch
    Original von contact
    Ja das mit den NSTimeIntervals klingt gut, reine doubles ...

    Dann muss ich mir nur mal Gedanken um die komplexeren Definitionen von Wiederholungen machen, Beispiel: an jedem zweiten Di alle drei Monate ?( oder nur Arbeitstage, da muss ich schon wieder Wochentage prüfen und die gehen derzeit nur mit der NSDateComponents-Sache!


    gibts aufm iPhone kein NSCalendarDate?

    btw: mit entsprechendem code-aufwand kannst du das alles BERECHNEN ;)

    NSCalendarDate ist in Cocoa schon ein Designfehler, weil ein Datum nicht von dem Kalender abhängt, in dem es notiert ist. Das ist in etwa so sinnvoll wie binary_int.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von gritsch
    der sauberste weg ist das nicht weil du nicht bis in die unendlichkeit daten reinballern kannst. Also woher weist du wie oft bzw wie lange sich ein wiederkehrender termin wieder holen soll?

    Ich meinte nicht das "auf 2 Jahre beschränken", ich meinte die Flag in der DB, ob ein Termin wiederkehrend ist oder nicht:

    Oder aber du schreibst wiederkehrende Events nur einmal ein (ausser natürlich sie beinhalten Änderungen) und beim Check für freie Termine vergleichst du bei nicht-wiederkehrenden Events weiterhin Start- und Schlusstimestamp, für die Wiederkehrenden prüfst du erst, ob das End-Datum in der Vergangenheit liegt und wenn nicht berechnest du, basierend auf dem Interval, ob ein Konflikt vorliegen wird.


    Wenn ein Event ein Enddatum hat (das lässt sich ja beim editieren des Events berechnen und als Timestamp speichern), schön und gut, wenn nicht ist das auch kein Problem, das ist dann halt einer der Events, welchen wir sowieso auf Überschneidungen prüfen müssen.
    Widgetschmie.de • Life is too short for gadgets