Dictionary lässt sich nicht als Datei speichern

  • Hmm,

    ich glaube für so ein Unternehmen würde ich lieber ne "richtige" Datenbank antesten.

    Warum nicht mal schauen, wie schnell das ist wenn man alles, also auch die Bilderdaten in eine sqLite Datenbank stopt und bei Bedarf quasi live abruft anstatt alles im Speicher zu haben...

    Was hälst du davon

    (oder nimm postgreSQL, dafür gibts ne bombastische Cocoa API und als Cluster...)
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • nen QT Film? *hmm* .. hätte ja was :)

    Ich hab das nun einmal auf der Ebene gemacht das pro Thumb eine Datei gespeichert wird.

    Quellcode

    1. -(void)writeImageToCache:(NSImage*)theImage fromPath:(NSString*)path {
    2. NSString *name,*filename;
    3. name = [NSString stringWithFormat:@"%@_%@",
    4. [[NSDate date] descriptionWithCalendarFormat:@"%y%m%d%H%M%S%F" timeZone:nil
    5. locale:[[NSUserDefaults standardUserDefaults] dictionaryRepresentation]],
    6. [[path lastPathComponent] stringByDeletingPathExtension]];
    7. filename = [NSString stringWithFormat:@"%@/%@.tif",IMAGECACHEPATH,name];
    9. if([[theImage TIFFRepresentation] writeToFile:filename atomically:NO])
    10. [imageCache setObject:filename forKey:path];
    12. return;
    13. }
    15. -(BOOL)existsImageInCacheForPath:(NSString*)filename {
    16. return [imageCache objectForKey:filename] == nil ? FALSE :TRUE;
    17. }
    19. -(NSImage*)readImageFromCacheForPath:(NSString*)filename {
    20. NSImage *thumb = [[NSImage alloc] initWithContentsOfFile:[imageCache objectForKey:filename]];
    21. return [thumb autorelease];
    22. }
    Alles anzeigen


    Das ist doch überraschend Fix das ganze.
    Einzig was stört, das der Thread in dem ich das ganze aufrufe dann mein Programm blockt.
    d.h es reagiert auf kein Event mehr.
    Das Programm ist er wieder bedienbar wenn der Thread vorbei ist.
    Ohne das _Caching_ kann ich auch während der Thread die Thumbs erstellt im Programm weiter navigieren.

    Nun setze ich mich einmal an die andere Lösung.

    Sven
    :wq! /dev/null

  • aber der einfache & schnelle zugriff fehlt. Außerdem wird der auch immer komplett geladen, das will er ja vermeiden.

    BTW: ich kann mich nur kressevadder anschließen. N ordner mit vielen kleinen Dateien und einem Index wird wohl auch für die Sauberkeit ein großer Vorteil sein. Große Dateien, in denen alles drinklebt sind seit OS X eigentlich out. Wenn es ein Cache ist, dann wird der sowieso irgendwo hin gespeichert und vom user nur selten aufgesucht wird, dann ist es ja auch egal, wie es aussieht...

    Max

  • Original von Stalkingwolf
    Kollege brachte mich aber auf ne andere Idee.
    Thumbs immer gleich groß in eine Datei schreiben.
    Datei beim laden öffnen, darin mit fseek an die Stelle der Bilder springen und per fread lesen. Beim beenden des Programmes den Dateipointer wieder schließen.

    Zwar Auffwand, aber wohl die schnellste und beste Idee.
    Somit habe ich auch nicht die Dateien die ganze Zeit im Speicher.

    Sven

    Stell dir das nicht zu einfach vor. Kaum ist das Programm verteilt gibt es das erste Thumnail, dass deine Grösse sprengt.
    Wie willst du erkennen wo das Bild zuende ist?
    Wie ist die Zuordnung von Bild und Thumbnail? Index? Reorganisation?

    Ich würde pro Image ein Thumb speichern, mit Namen des Bildes. Dann sparst du dir auch die .plist. Bei jedem Wechsel ins Directory im Hintergrund abgleichen.
    Die Images verwaltest du geschickt im Speicher. Caching macht das OS durch auslagern.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • Original von Chris
    Stell dir das nicht zu einfach vor. Kaum ist das Programm verteilt gibt es das erste Thumnail, dass deine Grösse sprengt.
    Wie willst du erkennen wo das Bild zuende ist?
    Wie ist die Zuordnung von Bild und Thumbnail? Index? Reorganisation?

    Durch feste Größen des Thumbnails/Bitmap. Damit ist der Block immer gleich groß.
    Ich muss nur mir merken welches Bild (Nummer) es genau ist und kann dann genau an die Stelle seeken. Mit einem read habe ich den ganzen Block heraus gelesen.
    Mit den Mod-Track Informationen mache ich nichts anderes.

    Aber ich hab das Thema erstmal verworfen, da die andere Methode wirklich so Wahnsinnig schnell ist. Selbst auf meinem G4 iBook 800MHZ läd das Programm die Bilder von der Platte ...
    Ich handtiere komplett ohne Cache im RAM. Alles auf der Platte. Nur das Dictionary mit den Keys und den Dateinamen des Thumbs behalte ich im RAM.

    Bin der Performance wirklich sehr überrascht.

    Sven
    :wq! /dev/null

  • Nachdem man ein Performance-Problem erkannt hat, macht man sich an die Optimierung, nicht vorher.

    "Premature Optimization is the root of all evil."

    Ich weiß, ich hatte das schon einmal erwähnt. Der Grund: Du ahnst nur, wo die Performance hängen bleibt. Das vorherzusagen ist extrem schwierig. Wenn du ein Performance-Problem hast, gibt es Tools, die genau ausfindig zu machen. Und der Nachteil: Du programmierst dir etwas komplex, nicht mehr an der eigentlichen Problemlösung und machst damit deinen Code unleserlich -- möglicherweise völlig ohne Grund.
    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 Tom9811
    Steht da ja. Wozu brauchst du denn die Transparenz bei einem Image-Browser? Willst du in collagierten Aquarellen browsen?

    Du dem anderen Senf gebe ich selber nun keinen Senf ab.

    Aber zu der Transparenz.
    Man mag es kaum glauben, aber es gibt PNG, ICNS und TIFF Bilder mit Transparenz und in dem Thumbnail sollte diese auch zu erkennen sein.
    Es schaut schrecklich aus, wenn der Hintergrund fest weiß oder schwarz ist.
    Und da die Zeilen in der Tabelle gestreift sind erst recht.

    Tom es ist ja nett das Du antwortest. Aber wenn dann einfach auf die Frage und nicht einfach immer alles in Frage stellen und schlaue Sprüche um dich werfen .. ok?!
    :wq! /dev/null

  • Aber wenn dann einfach auf die Frage und nicht einfach immer alles in Frage stellen

    Ich?

    Jerry schrieb:
    "TIFFs komprimieren ist ein Umweg, wieso nimmst Du nicht einfach Jpeg´s? Da kommst Du in die Gegend von 10-20kb."
    "Warum Cache? Verstehe ich nicht."

    mattik schrieb:
    "Bist Du da sicher? Bei einigen Sachen, die ich gemacht habe, war JPG schneller als unkomprimierte TIFFS."

    Chris schrieb:
    "Wie willst du erkennen wo das Bild zuende ist?
    Wie ist die Zuordnung von Bild und Thumbnail? Index? Reorganisation?"

    kressevadder schrieb:
    "Musst du die Bilder wirklich zwischenspeichern? Wenn es um das zurückgeben der neuen Daten aus dem Thread geht, kannst du ja auch "zurückrufen" wenn du fertig bist und die Daten übergeben."
    "Wird das nicht ganz schnell ne riesige Datenhalde? "
    "ich glaube für so ein Unternehmen würde ich lieber ne "richtige" Datenbank antesten."
    "Millionen Proxy Server, Internetbrowser und Webanwendungen können sich nicht irren"

    Michael schrieb:
    "Hmm, ob sich das wirklich lohnt? Ich mein, wieviel Prozent macht der Overhead denn an einem kompletten Lesevorgang eines Thumbs denn aus?"

    Bist du dir jetzt wirklich sicher, dass ich mich durch Infragestellen besonders hervorgetan habe?
    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"?

  • Aber wenn dann einfach auf die Frage und nicht einfach immer alles in Frage stellen

    Ich?

    Jerry schrieb:
    "TIFFs komprimieren ist ein Umweg, wieso nimmst Du nicht einfach Jpeg´s? Da kommst Du in die Gegend von 10-20kb."
    "Warum Cache? Verstehe ich nicht."

    mattik schrieb:
    "Bist Du da sicher? Bei einigen Sachen, die ich gemacht habe, war JPG schneller als unkomprimierte TIFFS."

    Chris schrieb:
    "Wie willst du erkennen wo das Bild zuende ist?
    Wie ist die Zuordnung von Bild und Thumbnail? Index? Reorganisation?"

    kressevadder schrieb:
    "Musst du die Bilder wirklich zwischenspeichern? Wenn es um das zurückgeben der neuen Daten aus dem Thread geht, kannst du ja auch "zurückrufen" wenn du fertig bist und die Daten übergeben."
    "Wird das nicht ganz schnell ne riesige Datenhalde? "
    "ich glaube für so ein Unternehmen würde ich lieber ne "richtige" Datenbank antesten."
    "Millionen Proxy Server, Internetbrowser und Webanwendungen können sich nicht irren"

    Michael schrieb:
    "Hmm, ob sich das wirklich lohnt? Ich mein, wieviel Prozent macht der Overhead denn an einem kompletten Lesevorgang eines Thumbs denn aus?"

    Bist du dir jetzt wirklich sicher, dass ich mich durch Infragestellen besonders hervorgetan habe? Für mich sieht das eher so aus, als ob hier niemand mehr über die ursprüngliche Fragestellung diskutiert.
    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 Tom9811
    "Premature Optimization is the root of all evil."

    Der Satz alleine reicht schon.
    Das ist in Fragestellen ohne einen konspirativen Hinweis warum und ohne sinnvolle Lösung.

    Dito zum Thema Transparenz
    Wenn ich der Meinung bin das ich die Benötige, dann ist das so.
    Dann kann man nicht schreiben:
    Transparenz wirst du bei einem Image-Browser kaum benötigen.


    Wie Du auch siehst habe ich mich von dem Vorhaben abhalten lassen und den anderen Weg eingeschlagen. Aber nöö, dann der Kommentar noch hinterher.
    Und Tom ... das ist nicht zum ersten mal so.

    @kressevadder
    Mir ging das Ding von Anfang an schon durch den Kopf.
    ich wollte nur einen Ordner von tausenden Dateien verhindern.
    Nun muss ich auch schauen, wenn der User in den Thumb Ordner wechselt.
    Sonst schreibt mein App Ihm die Platte voll.

    start:
    -> von den Thumbs werden Thumbs im selben Ordner erstellt
    -> Programm merkt das neue Dateien vorhanden sind und läd diese und erstellt wieder Thumbs
    goto start;

    :D Sven
    :wq! /dev/null

  • Das ist in Fragestellen ohne einen konspirativen Hinweis warum und ohne sinnvolle Lösung.

    1. habe ich das schon mehrfach erläutert, ich meine auch in diesem Thread, ohne das jetzt nachgeprüft zu haben.
    +++Update+++
    Doch, genau hier:
    "Ich weiß, ich hatte das schon einmal erwähnt. Der Grund: Du ahnst nur, wo die Performance hängen bleibt. Das vorherzusagen ist extrem schwierig. Wenn du ein Performance-Problem hast, gibt es Tools, die genau ausfindig zu machen. Und der Nachteil: Du programmierst dir etwas komplex, nicht mehr an der eigentlichen Problemlösung und machst damit deinen Code unleserlich -- möglicherweise völlig ohne Grund."
    Das ist ein äußerst konkreter Hinweis warum.
    Und die Lösung habe ich auch mitgelifert: Erst einmal die den Algo programmieren und dann mit Performance-Tools checken.
    Ich kann deinen Einwand nicht nachvollziehen.
    2. ist das ja nun wirklich eine Binsenweisheit.

    Wenn ich der Meinung bin das ich die Benötige, dann ist das so.

    Wie häufig gab es das schon, dass sich angeblich Benötigtes in Luft aufgelöst hat?

    Wie Du auch siehst habe ich mich von dem Vorhaben abhalten lassen und den anderen Weg eingeschlagen. Aber nöö, dann der Kommentar noch hinterher.
    Und Tom ... das ist nicht zum ersten mal so.

    Wo sehe ich das? Hinter was genau? Ich habe das nicht mitbekommen.
    Auch ansonsten wäre ich über Belege erfreut, wenn du derlei Anschuldigungen erhebst.
    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"?