[Vienna-pm] Garbage-Collection

[Peter J. Holzer]

On 2005-08-11 10:54:59 +0200, Carl A. Schreiber wrote:
> > Interessanterweise ist ein "manuelles" Abbauen des Hashes mittels delete
> > der einzelnen Elemente schneller ist als sich auf die Garbage-Collection
> > beim exit zu verlassen.
> >
> Ich hatte mal ein immer langsamer werdendes script, dass einen immer größer 
> werdendes array aufbaute. Das konnte ich ziemlich bescheunigen, in dem ich an 
> Stelle eines arrays (push bzw neues hash element) alles an einen string 
> klebte und am Ende (dazwischen brauchte ich die Dinge nicht) mit split wieder 
> in ein array splittete. Ich kann mir vorstellen, das diese Art auch 
> speichersparsamer ist!


Ja, die vielen kleinen Objekte, die Perl einzeln verwaltet, bedeuten
natürlich einiges an Overhead. Ich schätze, dass ich in C nur ca. 200MB
statt 1.3 GB RAM gebraucht hätte :-).

Prinzipiell fallen mir natürlich schon ein paar Methoden ein, wie man in
dem Fall Speicher hätte sparen können: Z.B. war die Anzahl der Keys in
der mittleren Ebene beim Programmstart bekannt. Statt 

$tp->{$token}{$corpus_name}[$idx] 

hätte ich daher auch

$tp[(($token_idx * $nr_of_corpora) + $corpus_idx) * 3 + $idx]

schreiben können und in zwei anderen Hashes ein Mapping von $token bzw.
$corpus_name auf die entprechenden numerischen Indices mitführen können.
Wenn man das Array gleich in einer plausiblen Größe anlegt, muss es auch
nicht allzu oft vergrößert werden.

Und dann gibt es ja noch ein paar Module für das Rechnen mit großen
Matrizen, damit sollte man dann in ähnliche Bereiche wie bei C kommen.

Aber das war ja eigentlich nicht mein Problem.


> Nimm halt geeignete delimiter zB  $delim = "\021" ist 
> der vertical Delimiter, der wird praktisch nie verwendet!
> 
> Das ständige Umkopieren eines immer größer werdenden array kostete ziemlich 
> viel Zeit in Perl! 
> 
> Ein Array (== Hash) wird in Perl ja mit eine best. Größe angelegt und wenn die 
> Größe überschritten wird es in einen gößeren (doppelt?) umkopiert.
> Mit delete kannst Du nun wahrscheinlich genau diese wiederholten 
> 'Schwellenüberschreitungen' hoch, runter,hoch, runter, .. vermeiden, desshalb 
> ist's wahrscheinlich schneller.

Nein, bei der Garbage-Collection geht's ja nur runter, nie rauf. Und die
Objekte werden als ganzes freigegeben: Wenn z.B. ein Hash mit 250000
Elementen out-of-scope geht, dann muss zwar für jedes Element der
Reference-Counter dekrementiert und geprüft werden, aber das Hash an
sich wird als ganzes freigegeben: Es kann nicht passieren, dass es mit
100000 Elementen weiterexistiert.

Ich vermute dass GC langsamer ist als manuelles Abbauen, weil die
Reihenfolge anders ist: Beim manuellen Abbauen verschwindet immer ein
Teilbaum auf einmal: Das sind Daten, die auch gemeinsam angelegt wurden
und daher wahrscheinlich nahe beisammen im Memory liegen: Da muss wenig
geswappt werden. Das GC kommt es darauf an, ob die Reference-Counts
depth-first rekursiv abgearbeitet werden oder breadth-first: Im
letzteren Fall sind die Memory-Zugriffe zumindest im Fall meines Scripts
ziemlich zufällig: Es muss ziemlich viel geswappt werden.

	hp

-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | hjp at hjp.at         |
__/   | http://www.hjp.at/ |	-- Holger Lembke in dan-am
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050811/d0b7f692/attachment.bin