David Haller wrote:
BTW Andreas: musst du per Exchange/Vodafone hier mitschreiben? Die fehlenden References/In-Reply-To sind doch etwas unschoen.
Ich weiss!
Da ich deine Mails gerne lese und schaetze, wuerde ich mich freuen, wenn du auf
Danke für die Blumen
einem anderen Wege hier mailen wuerdest und/oder den $Verantwortlichen beibiegen koenntest, dass sie Exchange, oder was auch immer du als "MUA" verwendest, RfC-konform konfigurieren sollen.
Sorry, nein. (hast Du schon mal in 'nem grossen Unternehmen gearbeitet? Da gibt's den Standard. Den darfst / musst Du verwenden und sonst nix. Bis vor kurzem konnte ich (illegalerweise) via KMAIL und POP3 meine Mails Inhouse abholen (nicht alle; aber die Linux-Listen schon). Doch dazu habe ich eine nicht genehmigte Linux Installation laufen gehabt (nicht weitersagen!). Ich weiss nicht, ob Du dir auch nur ansatzweise vorstellen kannst wie ich unter diesen Out-Dreck leide. Aber es gibt hier nix anderes (insbesondere nicht für externe MA).
Am Thu, 11 Nov 2004, Kyek, Andreas, VF-DE schrieb:
David Haller wrote: [..]
Evtl. waere es noch klarer, wenn du statt fetchrow_array ein fetchrow_hashref verwendest und dann [..] Allerdings ist das weniger performant als mit _arrayref oder _array.
Meine DBI Doku empfiehlt hier (wenn Performance interessant ist) folgendes Konstrukt zu verwenden:
--- cut here --- my sth = $dbh-prepare ...
my $sth = $dbh->prepare ...
$sth->execute ($username) or ...; $sth-bind_columns ( \($result_username, $result_pwd) ) or ...;
$sth->bind_columns(..);
while ($sth-fetch) {
while ($sth->fetch) {
Sach ma, hast du noch keinen Kaffee gehabt?
Nö (ein wenig hektischer gestern). Aber es ging mir auch mehr ums Prinzip (und das hast ja zumindest Du verstanden).
[..]
Laut Doku ist ein fetchrow_array oder auch ein fetchrow_hashref langsamer (aber das wird man erst bei richtigen Datenmengen bemerken können).
Hm.
"Man nehme" ne DB mit 2 Spalten "user_id" und "login" (und ggfs. mehr Spalten). 'user' und 'pass' anpassen!
[...]
Komischerweise(?) ist die bind-Variante gerade bei "groesseren" Datenmengen / Iterationen nicht die schnellste... Zumindest bei diesem Zugriffsmuster eben...
Ich habe nun mal gerade die aktuelle Doku (DBI-1.45) ausgedruckt. Auch hier steht: --cut here --- fetchrow_arrayref $ary_ref = $sth->fetchrow_arrayref; $ary_ref = $sth->fetch; # alias Fetches the next row of data and returns a reference to an array holding the field values. Null fields are returned as undef values in the array. This is the fastest way to fetch data, particularly if used with $sth->bind_columns --- cut here --- Hier wird meine Aussage allerdings relativiert: --- cut here --- fetchall_arrayref [...] If $max_rows is defined and greater than or equal to zero then it is used to limit the number of rows fetched before returning. fetchall_arrayref() can then be called again to fetch more rows. This is especially useful when you need the better performance of fetchall_arrayref() but don't have enough memory to fetch and return all the rows in one go. Here's an example: my $rows = []; # cache for batches of rows while( my $row = ( shift(@$rows) || # get row from cache, or reload cache: shift(@{$rows=$sth->fetchall_arrayref(undef,10_000)||[]}) ) ) { ... } That can be the fastest way to fetch and process lots of rows using the DBI, but it depends on the relative cost of method calls vs memory allocation. A standard while loop with column binding is often faster because the cost of allocating memory for the batch of rows is greater than the saving by reducing method calls. It's possible that the DBI may provide a way to reuse the memory of a previous batch in future, which would then shift the balance back towards fetchall_arrayref(). --- cut here ---
Und wenn man nur eine UID abfraegt (siehe ersten Vergleich) ist sogar hashref schneller als arrayref... Ob fuer einen der Unterschied hashref zu arrayref oder array signifikant ist (unter Beachtung der besseren Lesbarkeit bei den hashref und bind Varianten) muss man wohl je nach Anwendung entscheiden.
Die bind-Variante scheint aber wohl die Lesbarkeit mit der Performance zu kombinieren.
Im konkreten Fall sollte man wohl selber mal einen Benchmark wie oben auf die DB loslassen ;)
-dnh
--
I hate black text on a white background on CRTs. Too damned bright. You're right. Black text on a black background is so much more restful. -- J. Bowden and Tanuki
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com