nicht angemeldet
Wieso? - Storable liest genauso die ganze Datei ein, wie du auch über deinen Lösungsweg
machen musst. Zudem hat Storable ein C-Backend, was es doch ganz schön schnell macht,
eval hingegen (wohl auch auf C basierend...) muss den eingelesenen String zuerst
parsen, dann wird er in einen Perl-Parsed-Tree umgewandelt und dann interpretiert, wie
das mit allen Perlprogrammen geschieht; das macht die Sache eben langsam.
Das eval langsam ist verkündige ich ja auch schon seit Jahren (vor allem bei JS).
Was ich meinte ist, du kannst mit Storable nur ein Variabel auf einmal speichern und lesen.
Und was ich nur im 1.Posting andeutete, verwende ich Data::Dumper und DB_File genmeinsam, um komplexere Strukturen abzuspeichern und zu laden. Also die einzelnen Strukturen des Hash per Dumper speichern und mit eval einlesen. Das ist herrlich flexibel (und ich hoffe bei meinen Datenbanken noch halbwegs performant)
Ich hab grad in der MLDBM Doku gelesen, das auch dort mit Data::Dumper gearbeitet wird, allerdings Storable (wegen Geschwindigkeit) empfohlen wird.
eval sollte aber keine Probleme machen, da der Inhalt ja nicht ausgeführt wird, sondern der output von Data::Dumper, der (oder verläßt mich da meine Vorstellungskraft) keinen Code enthält, sondern Strings, die die Datenstruktur darstellt.
Auch Strings gehören zu Perl und werden interpretiert, genauso wie Befehle. Natürlich
gibt es bei Data::Dumper nicht viel "auszuführen", dennoch wird der Code (und _das_ ist
er dennoch) zuerst geparsed und dann interpretiert, ob dies nun eine Variablendeklaration
oder ein Befehl ist, spielt Perl eigentlich keine Rolle.
Ja aber, der "code" wird ja erst erzeugt von Dumper und dann geparst.
use Data::Dumper;
my $test ="system dir";
my $VAR1 = Dumper($test);
eval $VAR1;
Da passiert nichts.
Struppi.