Index suchen in einem NSArray mit vielen NSObjects (keine NSDictionaries)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Index suchen in einem NSArray mit vielen NSObjects (keine NSDictionaries)

    Hallo Forum,

    ich hab ein Problem und finde keine elegante und schnelle Lösung. Was ich gefunden habe, bezieht sich immer auf NSArrays denen ein NSDictionary hinzugefügt wurde und ich glaube, hier verhält es sich anders..

    Ich erzeuge ein NSArray und füge diesem viele gleiche NSObjects (Beispiel unten) hinzu.
    Später möchte ich dann den Index bzw. das Objekt holen, welches die 'uniqueNumber == 42 hat.
    Ich kann natürlich einen Schleifendurchlauf über alle Objekte durchführen und dann die 'uniqueNumber' vergleichen, ich hoffe aber, dass es da eine elegantere und bestimmt auch schnellere Lösung gibt.

    Vielen Dank für Vorschlage und Ideen!
    Gruß MIchael

    Datei '"TrackDynamic.h"':

    Quellcode

    1. #import <Foundation/Foundation.h>
    2. @interface TrackDynamic : NSObject
    3. @property (readonly) NSNumber *uniqueNumber;
    4. @property (readonly) NSString *orderHead;
    5. @property (readonly) NSString *orderTail;
    6. @property (readonly) NSString *comment;
    7. @property (readonly) unsigned short destPrimary;
    8. @property (readonly) unsigned short destSecondary;
    9. @property (readonly) unsigned short quality;
    10. @property (readonly) unsigned short palletType;
    11. @property (readonly) unsigned short palletSupplier;
    12. @property (readonly) unsigned short algoPrio;
    13. @property (readonly) unsigned short occupied;
    14. @property (readonly) unsigned short accuLikeSegTailOcc;
    15. @property (readonly) unsigned short stopped;
    16. + (id) createObjectWithTelegram: (LVS_TRACK_DYNAMIC_ST) telegram;
    17. - (id) init;
    18. - (id) initWithTelegram: (LVS_TRACK_DYNAMIC_ST) telegram;
    19. @end
    Alles anzeigen



    Die Objekte werden wie folgt hinzugefügt:

    'IrgendEinViewController.m'

    Quellcode

    1. - (void) processTrackDynamic: (NSNotification*) notifaction
    2. {
    3. SingletonCenter *singletonData = [SingletonCenter sharedSingleton];
    4. TrackDynamic *trackDynamic = [[notifaction userInfo] valueForKey:@"SEARCHKEY"];
    5. // add telegram to array
    6. [singletonData.trackDynamicArray addObject:trackDynamic];
    7. }
  • Michael_1965 schrieb:

    Ich erzeuge ein NSArray und füge diesem viele gleiche NSObjects (Beispiel unten) hinzu.

    Nein, Du fügst dem Array TrackDynamic Objekte hinzu.

    Michael_1965 schrieb:

    Später möchte ich dann den Index bzw. das Objekt holen, welches die 'uniqueNumber == 42 hat.

    Nichts leichter als das. In der Dokumentation findest du viele nützliche Methoden, dieses zu tun. Für Deinen Fall bietet sich zum Beispiel indexOfObjectPassingTest: an.
  • Michael schrieb:

    Michael_1965 schrieb:

    Ich erzeuge ein NSArray und füge diesem viele gleiche NSObjects (Beispiel unten) hinzu.

    Nein, Du fügst dem Array TrackDynamic Objekte hinzu.

    Michael_1965 schrieb:

    Später möchte ich dann den Index bzw. das Objekt holen, welches die 'uniqueNumber == 42 hat.

    Nichts leichter als das. In der Dokumentation findest du viele nützliche Methoden, dieses zu tun. Für Deinen Fall bietet sich zum Beispiel indexOfObjectPassingTest: an.


    ob das schneller oder übersichtlicher als eine schleife ist wage ich zu bezweifeln ;)

    beschleunigen könnte er es zb wenn er die uid nicht als NSNumber sondern als long o.Ä. verwenden würde (falls es wirklich um geschwindigkeit geht)
  • Es würde sicher auch was bringen wenn er beim Einfügen nach der ID sortieret einfügen würde. Dann kann er die ID später mit einem beliebigen Searchalgorithmus schneller finden.

    Darf ich mal Fragen was "TrackDynamic" ist? Weder die Developer Dokus noch Google findet da irgendwas im Bezug auf OSX oder iOS.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Michael schrieb:

    gritsch schrieb:

    ob das schneller oder übersichtlicher als eine schleife ist wage ich zu bezweifeln

    Ich hab's ja erwartet, dass sowas kommt. ;) Dazu sag ich nur:
    Donald Ervin Knuth:
    premature optimization is the root of all evil

    Und was an dem quasi Einzeiler unübersichtlich sein soll, erschließt sich mir nun gar nicht.


    geschwindigkeit war ja seine forderung. ich hoffe er hat das nicht nur so geschrieben ;)
    es ist gleich ein dreizeiler wie eine schleife. sieht aber beides besser aus wenn mans auf mehrere zeilen verteilt...
  • AFAIK sind sämtliche NSArray Methoden um Längen schneller als eigenes Gefrickel, da das NSArray Cluster im Zweifel intern die Methoden wechselt.
    ridiculousfish.com/blog/posts/array.html

    Man könnte sich auch einfach mal auf die Qualität der Arbeit Anderer verlassen…
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:

    AFAIK sind sämtliche NSArray Methoden um Längen schneller als eigenes Gefrickel, da das NSArray Cluster im Zweifel intern die Methoden wechselt.
    ridiculousfish.com/blog/posts/array.html

    Man könnte sich auch einfach mal auf die Qualität der Arbeit Anderer verlassen…


    und auf was beziehst du dich konkret (auf welche aussage hier im forum passt welche aussage in deinem link?)
  • gritsch schrieb:

    und auf was beziehst du dich konkret (auf welche aussage hier im forum passt welche aussage in deinem link?)

    Auf Metaaussagen.

    gritsch schrieb:

    ob das schneller oder übersichtlicher als eine schleife ist wage ich zu bezweifeln

    Übersetzt: Für mich steht fest, dass die bei Apple garantiert nicht daran gedacht haben ordentlich auf Geschwindigkeit zu optimieren.
    So it sure looks like CFArray is switching data structure implementations around 30,000 elements. And I believe there's lots more implementations that I haven't discovered, for smaller arrays and for immutable arrays.

    Übersetzt: Augenscheinlich haben die bei Apple daran gedacht, ordentlich auf Geschwindigkeit zu optimieren.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:

    gritsch schrieb:

    und auf was beziehst du dich konkret (auf welche aussage hier im forum passt welche aussage in deinem link?)

    Auf Metaaussagen.

    gritsch schrieb:

    ob das schneller oder übersichtlicher als eine schleife ist wage ich zu bezweifeln

    Übersetzt: Für mich steht fest, dass die bei Apple garantiert nicht daran gedacht haben ordentlich auf Geschwindigkeit zu optimieren.
    So it sure looks like CFArray is switching data structure implementations around 30,000 elements. And I believe there's lots more implementations that I haven't discovered, for smaller arrays and for immutable arrays.

    Übersetzt: Augenscheinlich haben die bei Apple daran gedacht, ordentlich auf Geschwindigkeit zu optimieren.


    und was willst du uns damit sagen? dass eine schleife NICHT schneller ist als indexOfObjectPassingTest?
    kleiner tipp: sie IST schneller ;)
  • gritsch schrieb:

    und was willst du uns damit sagen? dass eine schleife NICHT schneller ist als indexOfObjectPassingTest?

    Dass eine Schleife nicht immer schneller sein muss als indexOfObjectPassingTest.
    Hängt natürlich von der Komplexität der Objekte im Baum, der Anzahl eben dieser und der Komplexität des Tests ab.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:

    gritsch schrieb:

    und auf was beziehst du dich konkret (auf welche aussage hier im forum passt welche aussage in deinem link?)

    Auf Metaaussagen.

    gritsch schrieb:

    ob das schneller oder übersichtlicher als eine schleife ist wage ich zu bezweifeln

    Übersetzt: Für mich steht fest, dass die bei Apple garantiert nicht daran gedacht haben ordentlich auf Geschwindigkeit zu optimieren.
    So it sure looks like CFArray is switching data structure implementations around 30,000 elements. And I believe there's lots more implementations that I haven't discovered, for smaller arrays and for immutable arrays.

    Übersetzt: Augenscheinlich haben die bei Apple daran gedacht, ordentlich auf Geschwindigkeit zu optimieren.

    In diesem Fall ist Apples Ansatz aber genereller. Das kann sogar bei besserer Codequalität, die ich auch unterstellen will, dazu führen, dass es eine schlechtere Performance gibt.
    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"?
  • Marco Feltmann schrieb:

    gritsch schrieb:

    und was willst du uns damit sagen? dass eine schleife NICHT schneller ist als indexOfObjectPassingTest?

    Dass eine Schleife nicht immer schneller sein muss als indexOfObjectPassingTest.
    Hängt natürlich von der Komplexität der Objekte im Baum, der Anzahl eben dieser und der Komplexität des Tests ab.


    nein eben nicht, denn egal wie komplex zb der test ist, diesen musst du genauso in der schleife wie auch im block machen.
    bei der schleife fällt eben das kopieren des blocks weg ;)