Ressourcenverbrauch optimieren
-
CarstenJ schrieb:
Wenn du z. B. riesige Logfiles einliest und diese verarbeitest, sind u. U. 350 MB ok.
Naja, nur wenn es sich überhaupt nicht umgehen lässt; normalerweise würde ich dann einfach nicht alles auf einmal in den Speicher packen...
-
Horst2 schrieb:
Es ist nur eine Datei, sie ist 273 KB groß
Uh, dann sind 350MB RAM _ganz_ sicher zu viel; zeig mal Code.
-
Kann es sein, dass du einfach nur einen Umrechnungsfehler beim Blick in den Taskmanager gemacht hast und dein Programm nur 3,5 MB oder so verbraucht? Also bei ~350 MB zuviel muss etwas sehr gewaltig schief laufen...
-
hab jetzt zum zweitenmal so ne unglaubliche frage gehört. und zum zweiten mal hatte es was mit xml und microsoft zu tun.
kann es sein, daß der ms-xml-parser einfach immer alles gelesenen im ram lagert? kann es sein, daß er für solche anwendungen einfach schrott ist? kann es sein, daß man in nur 20 minuten nen erstaz gebaut hat, der dieses eine logfile zufriedenstellend lesen kann?
-
Das mit dem Ersatz mag stimmen, allerdings kann ich den Rest nicht nachvollziehen. Der XML-Parser von MS ist zwar nicht der Beste, aber so gravierende Fehler macht er nicht (zumidest wenn man ihn richtig benutzt).
-
kann es sein, daß der ms-xml-parser einfach immer alles gelesenen im ram lagert?
Das ist das DOM Modell. Wie viel Overhead der Parser noch zusätzlich bringt weiss ich nicht. Aber ein Umstieg auf SAX sollte einiges retten (wobei das eher zum ausbügeln des Design Fehlers dient :))
kann es sein, daß man in nur 20 minuten nen erstaz gebaut hat, der dieses eine logfile zufriedenstellend lesen kann?
man kann auch ein besseren Parser nehmen. libxml2 soll extrem schnell sein, hat aber leider eine C API.
Ansonsten frag ich mich, wer auf die Idee gekommen ist XML für Logdateien einzusetzen. Dafür ist XML absolut ungeeignet IMHO.
-
Also soweit ich das verstanden habe ging es nie um Logfiles. Das war nur eine Mutmaßung seitens der antwortenden Personen in diesem Thread bevor klar wurde, dass es sich um etwas wie eine Artikeldatenbank handelt.
-
DOM wird eigentlich auch nur dann benutzt, wenn man das File editieren muss. Zum reinen Einlesen nimmt man SAX-Parser.
-
Für eine Artikeldatenbank sollte man auch wirklich eine Datenbank und keine XML Datei nutzen. Ich denke mal man könnte einiges an Ressourcen sparen wenn man ein kleines Prog schreibt um die Daten in eine vernünftige Datenbank zu stopfen (mit dem XML Parser). Die Überprüfung findet dann mit der Datenbank statt...das sollte insgesamt mehr Performance bringen oder???
-
Vielleicht haben wir ja hier schon eine Optimierung gefunden? :p
-
Nach meiner Erfahrung ist der MS Parser eigentlich einer der schnellsten. Hat sich da irgendjemand schon die Mühe gemacht, die verschiedenen Parser zu benchen?
-
5(0rP: Ich denke nicht, dass eine Datenbank unbedingt so merkbar schneller ist, zumal man sich die lächerlichen ~300 kB auf allen in Frage kommenden Plattformen auch im Speicher halten kann und dann mit einer hashtable auf die Artikel zugreift.
-
Es ist trotzdem immer eine gute Idee an die Zukunft zu denken. Datenbanken haben normalerweise die unangenehme Eigenschaft das sie wachsen, wachsen und immer weiter wachsen.
-
5(0rP schrieb:
Es ist trotzdem immer eine gute Idee an die Zukunft zu denken. Datenbanken haben normalerweise die unangenehme Eigenschaft das sie wachsen, wachsen und immer weiter wachsen.
...und mitunter verdammt bloatig sind.