Re: [gelöst]Re: /bin/sh: prüfen ob String1 "Wort" aus String2 enthält
Hallo,
On Tue, 3 Jan 2017 20:57:55 +0100
Christian Knoke <chrisk@cknoke.de> wrote:
> Michael Lange schrieb am 03. Jan um 19:11 Uhr:
> > On Tue, 3 Jan 2017 08:49:19 +0100
> > Jochen Spieker <ml@well-adjusted.de> wrote:
>
> > Wenn man die ganzen "Paketlisten" auf einmal an grep (oder wie von
> > Christian vorgeschlagen uniq) weiterreicht, ist das bestimmt
> > schneller, aber dann muss ich wieder über die Argumentlänge
> > nachdenken. Ich habe mir mal eine Beschreibung zum Thema auf
> > http://www.in-ulm.de/~mascheck/various/argmax/
> > angeschaut und bin dann für mich zum Ergebnis gekommen, dass ich davon
> > besser die Finger lasse, ich habe damit nicht wirklich das Gefühl,
> > dass ich "weiss was ich tue" und möchte nicht nochmal in die gleiche
> > Falle tappen.
>
> Das stimmt nicht. Wenn du das von mir vorgeschlagene
>
> ~$ echo $INSTALLED_PKGS $PKGNAMES | tr " " "\n" | sort | uniq -d
>
> mit grossen Paketlisten verwendest, nimmst du cat:
>
> ~$ cat INSTALLED_PKGS PKGNAMES | tr " " "\n" | sort | uniq -d
>
> in der pipe gibt es kein Problem mit "zu lang". Die Paketlisten sind
> dann ohnehin in Dateien gespeichert - hoffentlich. Wenn schon jeder
> Name sauber auf einer Zeile steht, kannst du es noch vereinfachen:
>
> ~$ cat INSTALLED_PKGS PKGNAMES | sort | uniq -d
>
> Die Aufgabe ist hier sehr simpel, die Schnittmenge zweier Listen. Der
> Algorithmus, sortieren und Doubletten ausgeben, dürfte ziemlich nahe am
> Optimum liegen, und skaliert mit n log n auch gut.
>
> Der Sinn, das mit bash-Mitteln lösen zu wollen, und die Listen in
> Variablen zu packen, liegt allein darin, sich die Anlage und den Umgang
> mit Dateien zu ersparen, weil man davon ausgeht, dass die CPU-Last
> keine Rolle spielt.
Ja, das ist definitv der Plan, zwischenspeichern in Dateien ist für mich
in diesem Kontext keine Option.
>
> Wenn es dir aber um Geschwindigkeit geht, und die Paketlisten länger
> werden
> - Debian hat weit über 40.000 - dann ist es klar, das die Lösung mit der
> Pipe schneller als jedes Shellscript ist.
>
> Mach ein paar Tests, dann ist es klar. Ich habe spasseshalber ein Tcl
> Script geschrieben, dass ist auch schneller als jede Shell, aber an die
> Pipe, an sort und uniq, kommt es nicht ran.
Naja, die Paketliste, aus der die Schleife bei der Shell-Lösung gebaut
wird, besteht ja nur aus den täglichen Updates, im Normalfall ist die
eher kurz. Richtig lang wird die nur bei Rechnern, die selten genutzt
werden und die Testing oder unstable installiert haben. Und wenn sich
dann tatsächlich mehr als 500 Pakete zum Updaten angesammelt haben, sind
die je nach Default-Shell und Rechenleistung anfallenden Zehntel- bis
ganzen Sekunden ja irgendwie auch das geringste Problem, das eigentliche
Upgrade zieht sich dann vor allem.
Die Performance bis zum Abwinken zu tunen ist hier sowieso nicht das Ziel.
Getestet habe ich ja schon so einiges. Z.B. den Python-Schnipsel, den ich
zuerst eingesetzt hatte, der brauchte in einem Testskript lt. time ca.
2/100 Sek. Das echo $INSTALLED_PKGS $PKGNAMES | tr " " "\n" | sort | uniq
-d ungefähr genauso, Ob da die eine oder andere Lösung eine hundertstel
Sekunde sparen kann, ist für diesen Einsatzzweck meiner Ansicht nach
wirklich belanglos. Das läuft ja normalerweise nur vllt. ein-oder zweimal
täglich.
Und selbst die Lösung mit der case-Konstruktion verbraucht
selbst bei unrealistisch grosser Menge an Update-Kandidaten vermutlich
wesentlich weniger CPU-Zyklen als ein Firefox Fenster beim Öffnen. Mit
320 Paketen (und realistisch gesehen sind das schon ziemlich viele)
braucht dash hier gerade noch 8/100 (bash allerdings fast eine halbe
Sekunde). Bei 120 Paketen: dash 2/100, bash 18/100 . Der
apticron-Algorithmus: 7,8 Sek.
Gruss
Michael
.-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-.
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
Reply to: