Warum hat OSX Probleme mit großen Datenmengen?

[weebee]

Ich habe gerade einen Thread gelesen, in dem es darum ging, dass iTunes wohl bei großen Datenbeständen sehr langsam wird und öfters den Beachball zeigt.

In einem anderen Thread geht's um die gleiche Problematik, nur das dort iPhoto das betreffenden Programm ist.

Ich selbst habe die leidliche Erfahrung machen müssen, dass nicht mal eine Datenbank-Software (iView) in der Lage ist, Datenbeständen mit mehreren zehntausend Dateien flüssig zu verwalten.

Auch der Finder kommt mit großen Datenmengen anscheinend nur schwerlich klar. Alleine das Öffnen eines Ordners mit vielen Dateien dauert schon einen Moment, wenn man dann einige oder alle markieren will, kann selbst das schon zum Problem werden. Beim Ziehen auf das Ziel muss dann sogar einen Moment die Maustaste festhalten, damit der Finder überhaupt mitbekommt, wo die Sachen hinsollen.

Alle Beispiele betreffen unterschiedliche Programme. Insofern kann es ja eigentlich kein OSX-Problem sein. Auffällig ist, dass die Probleme anscheinend exponentiell mit der Datenmenge ansteigen. Also wenn man mit beispielsweise 10.000 Dateien noch klar kommt, dauert's bei 20.000 nicht doppelt, sondern überproportional länger. 32.000 scheint bei allen Programmen eine magischen Grenze zu sein darüber wird's dann nochmal langsamer.

Wer sich mal einen Spass machen will, der kann mal 100.000 Dateien erzeugen (Finder > Duplizieren). Solche Datenmengen sind unter OSX praktisch nicht mehr handhabbar. (Im Terminal läuft hingegen alles superschnell.) Sicherlich ist es nicht unbedingt sinnvoll, mit diesen Datenmengen umzugehen; andererseits könnte man natürlich auch fragen »wozu haben wir die schnellen Rechner?«. Und das unter OSX liegende Darwin/BSD hat damit ja auch keine Probleme; Linux-Server zeigen ja auch, dass es prinzipiell gehen kann.

Ist das ein Problem irgendeines (nicht optimierten) Frameworks, das alle Programme nutzen?

 

[chsz87]

Also ich hatte noch nie ein solches Problem wie du hier beschreibst, obwohl ich sehr viel mit großen Datenmengen zu tun habe (vor allem mit iTunes ).
Bei mir läuft eigentlich alles ziemlich zügig und ich kann mich nicht beklagen.

Christoph

 

[michaelbach]

ich stimme zu dass das langsam wird. Wahrscheinlich macht der Finder beim Kopieren zu viel. Sieht man z.B. daran: eine Datei markieren, kopieren, und dann z.B. in Mail einfügen. Das kopiert die ganze Datei als Anlage hinein, nicht etwa nur den Dateinamen. D.h. dass der Finder beim Kopieren auch sowas wie ein Alias erzeugt.

Viele erhoffen ja von der nächsten großen MacOSX-Revision da einen besseren Finder...

 

[tjp]

Ist das ein Problem irgendeines (nicht optimierten) Frameworks, das alle Programme nutzen?

Es gibt wohl mehrere Ursachen, eines das auf alle Fälle alle Programme betrifft sind die extrem langsamen (in Relation zu anderen UNICES) Kontextswitches. Ein Kontextswitch tritt immer dann auf, wenn die Ausführung eines Prozesses oder Threads auf einen anderen Prozeß oder Thread umgeschaltet wird.

Das Problem ist kein Designfehler in dem Sinne, daß man mit einem Mach-Kernel keine schnellen Kontextswitches hinbekommen könnte. Tru64 (OSF/1 oder auch Digital UNIX genannt) hat auch einen Mach3 Kernel, aber nicht das Apple Problem.

Bei Anandtech gab es einen Vergleichstest von Linux und MacOX auf einem Xserve. Es stellte sich sehr deutlich heraus, daß MacOS X obiges Problem besitzt. Insofern verbrezelt MacOS X einen Großteil der CPU-Power mit Ineffizienz.

 

[michaelbach]

ich hab's grad mal spaßeshalber probiert [2xG5]: eine 1-Wort-Textdatei in einem Ordner. Apfel-a, dann Apfel-d. Bei der Verdopplung von 5500 dauerte es 2 min, und jetzt beim Verdoppeln von 11.000 ist er nach 30 min noch nicht fertig! Die Platte ist still, aber MenuMeters zeigt in beiden CPUs fast volle user load an.

 

[chsz87]

ich hab's grad mal spaßeshalber probiert [2xG5]: eine 1-Wort-Textdatei in einem Ordner. Apfel-a, dann Apfel-d. Bei der Verdopplung von 5500 dauerte es 2 min, und jetzt beim Verdoppeln von 11.000 ist er nach 30 min noch nicht fertig! Die Platte ist still, aber MenuMeters zeigt in beiden CPUs fast volle user load an.

Ist dir irgendwie langweilig?
Ich habe es auch probiert... Du hattest Recht, es dauert wirklich wesentlich länger...

Christoph

 

[weebee]

ich hab's grad mal spaßeshalber probiert [2xG5]: eine 1-Wort-Textdatei in einem Ordner. Apfel-a, dann Apfel-d. Bei der Verdopplung von 5500 dauerte es 2 min, und jetzt beim Verdoppeln von 11.000 ist er nach 30 min noch nicht fertig! Die Platte ist still, aber MenuMeters zeigt in beiden CPUs fast volle user load an.

Versuche danach mal einige (hundert oder tausend) Dateien anzuklicken (das ist bereits ein Problem) und diese in einen anderen Ordner zu verschieben.

 

[yjnthaar]

Moin,

Kann das einer mal mit Windows machen? Würd mich interessieren wie da der Finder Explorer reagiert.

Salve,
Simon

 

[KayHH]

Moin weebee,

man wird auch immer anspruchsvoller. Früher hat man stundenlang (1 bis 3) gewartet bis die 30 MB Vortex Festplatte am ATARI MEGA ST sich mal bequemt hat ein paar Tausend Dateien zu kopieren, heute kostet das kaum ein Augenzwinkern. 30 MB sind nun definitiv ein Witz. Beim Tausendfachen weiß ich, dass ich ein paar Minuten warten muss, aber es funktioniert. Irgendwo ist halt Schluss mit lustig. In den Mac Anfangstagen konnte man noch nicht mal ein paar Tausend Dateien kopieren OHNE das irgend was daneben ging. Das hat mich einige Nerven gekostet. Heute verwalte ich über 2 Mio. Dateien und verliere dank Spotlight nicht mal den Überblick. Okay iTunes wird langsamer, 16.000 Titel sind am iMac G5 2,1 aber kein Problem, ebenso wenig wie 10.000 Photos in iPhoto, aber irgendwo wird es halt langsamer. Was erwartest du? Die Mittel sind einfach begrenzt. Dank technischer Innovationen und voranschreitender Miniaturisierung kann da aber abgeholfen werden, nötiges Kleingeld voraus gesetzt. Quad core rulez!


Gruss KayHH

 

[mullzk]

Kann das einer mal mit Windows machen? Würd mich interessieren wie da der Finder Explorer reagiert.

sämtliche windows-versionen die ich bisher erlebt habe, waren keinen deut besser, einzig mit dem unterschied, dass sie nicht nur langsamer wurden, sondern nach drei viertel auch noch abstürzten. mit os x gehts lange, aber immerhin gehts normalerweise....

allerdings: dieselben probleme bei filemanagern kenne ich auch vom konqueror und unter solaris, brutal grosse verzeichnisse sind einfach immer ein killer.

für sehr viele aufgaben gibt es halt einfach keinen algoritmus mit linearer komplexität, sondern werden überproportional zum input langsamer. dies gibt es auch bei den brutalsten highend-systemen. aber: man kann algoritmen optimieren, und da ist apple in der tat nicht immer heldenhaft. gerade bei den consumer-produkten in ilife scheinen sie sich irgendwelche vorgaben zu machen, bis zu welcher datenmenge das ding brauchbar laufen muss, und was darüber ist, ist wurscht. iphoto ist da ein klassiker, wo sogar his steveness zugeben musste, dass man da mit viel zu kleinen datenmengen gerechnet habe.
allerdings ist dies auch nicht nur ein apple-spezifisches problem, microsoft zum beispiel scheint auch davon auszugehen, dass word-dokumente nur eine gewisse anzahl graphischer elemente und weniger als 50 seiten beinhalten. software, die sich auch für wirklich grosse datenmengen eignet, zu entwickeln, ist halt mit einem zusatzaufwand verbunden, und dann machen halt die meisten software-firmen betriebswirtschaftliche überlegungen, bis wie weit man perfektionismus betreiben muss....


und noch kurz zum textedit-experiment: textedit ist grosso modo einfach ein NSTextview-Konstrukt, eine Cocoa-Hierarchie die für quasi null programmieren sehr viele Funktionalität in Text-Eingabefelder hergibt. So beliebt sie auch ist, so berüchtigt ist auch ihre schlechte Performanz, gerade bei grösseren Texten. Mit grossen Files kann man dann meist auch relativ leicht zwischen Texteditoren, die auf NSTextView basieren von jenen Editoren unterscheiden, die das Textsystem eigenhändig implementiert haben.

 

[weebee]

man wird auch immer anspruchsvoller(…) Die Mittel sind einfach begrenzt.

Moin, ich kann das ja nachvollziehen was Du meinst, aber die Hardware ist ja auch bedeutend leistungsfähiger geworden. Und wie gesagt, das Apple-BSD hat viel weniger Probleme. Gleiches gilt natürlich für die vielen Server da draußen. 100.000 Dateien darf doch heute kein Problem mehr sein.

Die uns heute zur Verfügung stehende Rechenleistung ist eigentlich gigantisch, wir realisieren das nur nicht, da sie größtenteils von der Software wieder aufgefressen wird.

 

[weebee]

Kann das einer mal mit Windows machen? Würd mich interessieren wie da der Finder Explorer reagiert.

Wenn ich mich recht erinnere war das etwas flüssiger, der OS9-Finder war ja auch wesentlich schneller (den würde ich gerne mal auf 'nem Quad.G5 sehen ). Aber das ist mir eigentlich wurscht, ich arbeite nunmal mit OSX. Und da gibt's auch nix dran zu rütteln.

Aber meine Frage bezog sich ja auch nicht nur auf den Finder. Ich kam ja darauf wegen den beiden anderen Threads hier im Forum (iPhoto und iTunes). Und eben iView, was ja eine Datenbank sein soll schon bei 10-20.000 Dateien ständig den Beachball zeigt.

 

[Rastafari]

Wenn ich mich recht erinnere war das etwas flüssiger, der OS9-Finder war ja auch wesentlich schneller

Unsinn. Der brauchte zur Anzeige und zum Kopieren etc von vielen Dateien *bedeutend* länger als der heutige.
(Da sind Lichtjahre dazwischen.)

was ja eine Datenbank sein soll schon bei 10-20.000 Dateien ständig den Beachball zeigt.

"Datenbanken" erkennt man idR daran, das sie entweder gar kein Dateisystem brauchen oder mit nur einer Handvoll Dateien auskommen.

Was du meinst, sind "Dateiverwaltungswerkzeuge".
Und dass es nun mal eine Weile dauert, aus tausenden Bildern die Vorschauen sowie etliche andere Metadaten zu extrahieren könnte einleuchtend sein.

 

[newman]

sämtliche windows-versionen die ich bisher erlebt habe, waren keinen deut besser, einzig mit dem unterschied, dass sie nicht nur langsamer wurden, sondern nach drei viertel auch noch abstürzten. mit os x gehts lange, aber immerhin gehts normalerweise....

Ich geb dir ja oft und gerne recht, aber in diesem Fall nicht. Unter Windows 2000 und XP ist der Explorer deutlich leistungsfähiger und belastbarer als der Finder, ist zumindest meine Erfahrung. Ich hab viel mit sehr grossen Verzeichnissen und Unmengen an Dateien zu tun, unter OS X mach ich solche Sachen mittlerweile gerne mit der Konsole. Insgesamt kann es der Finder mit dem Explorer in keiner einzigen Kategorie aufnehmen und kein anderes Teil an OS X wird, IMO völlig zu Recht, derart oft kritisiert.

allerdings: dieselben probleme bei filemanagern kenne ich auch vom konqueror und unter solaris, brutal grosse verzeichnisse sind einfach immer ein killer.

Irgendwann geht alles in die Knie, Konqueror ist trotzdem insgesamt ein Stück performanter und belastbarer als der Finder - dabei für meinen Geschmack auch noch funktioneller.

für sehr viele aufgaben gibt es halt einfach keinen algoritmus mit linearer komplexität, sondern werden überproportional zum input langsamer. dies gibt es auch bei den brutalsten highend-systemen. aber: man kann algoritmen optimieren, und da ist apple in der tat nicht immer heldenhaft. gerade bei den consumer-produkten in ilife scheinen sie sich irgendwelche vorgaben zu machen, bis zu welcher datenmenge das ding brauchbar laufen muss, und was darüber ist, ist wurscht. iphoto ist da ein klassiker, wo sogar his steveness zugeben musste, dass man da mit viel zu kleinen datenmengen gerechnet habe.

So isses. Nettes Beispiel dazu ist auch Pages. Für ein erstes Release eigentlich sehr gelungen, aber lahm.

allerdings ist dies auch nicht nur ein apple-spezifisches problem, microsoft zum beispiel scheint auch davon auszugehen, dass word-dokumente nur eine gewisse anzahl graphischer elemente und weniger als 50 seiten beinhalten. software, die sich auch für wirklich grosse datenmengen eignet, zu entwickeln, ist halt mit einem zusatzaufwand verbunden, und dann machen halt die meisten software-firmen betriebswirtschaftliche überlegungen, bis wie weit man perfektionismus betreiben muss....

Nicht nur Word, auch mit OOo und allen anderen überpackten Textverarbeitungen. Bei diesen Dingern wird im Hintergrund permanent das Layout neu gerechnet, die Leute wollen unbedingt WYSIWIG, dabei aber layouten wie ein DTP'ler, das geht immer in die Hose. Wenn ich all das abstelle, hab ich im Prinzip Subethaedit, nur das will ausser uns Codern keiner. Übrigens geht auch das irgendwann in die Knie, ist auch logisch, probehalber einfach mal 'nen 10 MB großen SQL-Dump laden und der Beachball ist dein Freund. Das Ganze mit 1 GB Arbeitsspeicher. Smultron ist da etwas besser, aber bei solchen Dateien auch total zäh.

und noch kurz zum textedit-experiment: textedit ist grosso modo einfach ein NSTextview-Konstrukt, eine Cocoa-Hierarchie die für quasi null programmieren sehr viele Funktionalität in Text-Eingabefelder hergibt. So beliebt sie auch ist, so berüchtigt ist auch ihre schlechte Performanz, gerade bei grösseren Texten. Mit grossen Files kann man dann meist auch relativ leicht zwischen Texteditoren, die auf NSTextView basieren von jenen Editoren unterscheiden, die das Textsystem eigenhändig implementiert haben.

Welcher basiert nicht auf NSTextview, bzw. welcher ist derzeit der schnellste?

 

[mullzk]

vi ist natürlich der schnellste
wer es etwas gemütlicher und schöner will: mit bbedit bin ich bisher auch noch nie in eine grössenbeschränkung gerasselt.

 

[newman]

vi ist natürlich der schnellste
wer es etwas gemütlicher und schöner will: mit bbedit bin ich bisher auch noch nie in eine grössenbeschränkung gerasselt.

vi ist sehr flott, aber in der Shell nutze ich lieber nano, ist auch sehr zügig zugange und hat keine Probleme mit großen Dateien.

Ich arbeite lieber in der GUI, deshalb hab ich mir auf deinen Tipp bezüglich bbedit mal dessen kleinen Bruder Textwrangler gesaugt und siehe da, hat überhaupt kein Problem mit Monsterfiles, hab ihn eben mit 'nem großen SQL Dump getestet. Ist genau was ich gesucht habe!

Dank dir, mullzk.

 

[angelone]

frage:
wiso habt ihr irren eigentlich ordner mit 100000 dateien drin, die ihr gerne per drag&drop rumkopieren wollt?
und wiso macht ihr das so oft, dass euch die paar minuten wartezeit stören?

meine stats:
itunes 3600 mp3s.
gar keine wartezeit bim öffnen und anklicken irgendeiner datei

iphoto 3000 photos
starten und damit verbundenes anzeigen der gesamten photobibliothek als thumbs knapp 5 sekunden

alle photos markieren keine wartezeit
alle photos draggen hat knapp 3sec verzögerung bis der mitkriegt das sich die draggen will
droppen auf nen desktopordner hat auch knapp 3sec verzögerung

dann fängt der an das kopieren vorzubereiten, was nochmal knapp 10sec braucht.

is jetzt imho kein beinbruch
das sind schliesslich 3000 dateien leute...

ich hab btw ein 12" powerbook 1,33ghz und 786mb ram

 

[Harald909]

iphoto 3000 photos
starten und damit verbundenes anzeigen der gesamten photobibliothek als thumbs knapp 5 sekunden
ich hab btw ein 12" powerbook 1,33ghz und 786mb ram

Hm, bei mir dauert iPhoto mit 4500 Bildern 12 bis 14 Sekunden. Das ist schon einige Zeit. Picassa auf Windows XP ist da bei gleicher Menge wesentlich schneller.

 

[yjnthaar]

Moin,

Die "Wartezeiten" sind schon der Hammer!
Also erlich? Wie lange ist Mensch früher (so vor 5 Jahren) vor ner Internetseite gehockt, bis die 20 KB GIFs geladen waren? 15 Sekunden? Ein Witz. So schnell kann ich meine Fotos gar nicht kucken. Gut ich mach das alles mit Portfolio inzwischen. Da sind die Dinger "einkatalogisiert" und es gibt keine Wartezeit. Nur beim katalogisieren eben.

However. Ich finde ne Wartezeit von bis zur einer Minute pro 5000 Bilder akzeptabel, so lange die Bilder sequenziell geladen werden und ich die ersten schonmal sichten kann.

Nur meine Meinung...nichts weiter. :-D


Salve,
Simnon

 

[KayHH]

Moin apfeltalker,

Unsinn. Der brauchte zur Anzeige und zum Kopieren etc von vielen Dateien *bedeutend* länger als der heutige.
(Da sind Lichtjahre dazwischen.)

das kann ich auch nur bestätigen und das schlimmste dabei, manchmal hat es gar nicht funktioniert. Mitten im Kopieren einer großen Datenmenge kommt ein Fehler. Das Problem dabei war, dass man nicht feststellen konnte wo genau der Finder hängen geblieben ist, um dann mit genau dem fehlenden Rest fortzusetzen. Ich habe dann alles wieder gelöscht und Häppchenweise kopiert. Das war wirklich kein Spaß. Zum Glück musste ich nicht so oft große Datenmengen kopieren.


Gruss KayHH