File- Directoryscan Linux vs Windows

[Ralf]

Hallo Leute,

ich habe festgestellt, dass Windows7 wesentlich schneller die Festplatten durchsucht, als Linux.
Ich würde gerne heraus bekommen, warum das so ist.

Details:
Ich benutze Kubuntu 16.04 LTS als mein Standard-OS und habe hier als Host VirtualBox 5.1.10 installiert.

Win7:
Mit VirtualBox benutze ich ein Win7 Gast mit CodeTyphon (5.9) und compiliere damit ein Beispielprojekt, welches Dateien (hier Fotos) rekusiv ab einem ausgewählten Startdirectory sucht.
Zur Zeitmessung/Performanceanzeige habe ich es leicht modifiziert (zeige in Label1 den Status an).

Auf meiner Datenplatte (NTFS) liegen ca. 80.000 Fotos in verschiedenen Unterordnern. Der Scan dauert unter Win7 ca. 52 Sek.

Linux:
Als weiteres Gastsystem habe ich Kubuntu 14.04 LTS mit CoeTyphon 6.0 am Start.
Das selbe Beispielprogramm habe ich hier ebenfalls compiliert. Aus dem Gast heraus benötigt das Programm 1000 Sek., also ca. 20 mal solange.

Nacharbeit, weitere Tests:
Ich dachte, dass NTFS vielleicht "besser" bzw. schneller bei solchen Operationen sei und Linux das nicht nutzen kann. Also habe das Fotoverzeichnis inklusive der 80.000 Fotos auf eine exterme HD mit ext4 kopiert und den Test wiederholt.
Das selbe Ergebnis. Windows ist aus dem VB-Gast heraus auch auf der ext4-Platte 20 mal schneller (quasi kein Unterschied zur NTFS Platte).

Ich habe das Linuxprogramm sogar ohne VirtualBox direkt auf dem Host ausgeführt. Genauso lahm wie im Gast!

Was mag der Grund dafür sein?

Ich habe mal den Code beider Projekte (Win und Linux) im Anhang und die compilierten Programme inkl. Screenshots der Ergebnisse von Windows und Linux.

Weiß jemand Rat, wie das unter Linux flotter geht?

(Die selben Files aus meiner Cloud):
https://drive.google.com/file/d/0B08wTf ... sp=sharing


Viele Grüße,
Ralf

[Warf]

Ein solcher Zeitunterschied ist nur durch anderes Cache handling zu bekommen. Wahrscheinlich hat windows einfach die Dateiinformationen zu großen teilen im Cache (oder die ordnerstrukturen) und Linux nicht. Windows nimmt Fotos glaube ich schon beim plugin der platte oder beim ersten öffnen des Ordners mit dem explorer in den Cache auf. Interessant wäre es mal für binärdateien, Musik (sollte ähnlich zu Bildern sein), Dokumente und Textdateien das zu testen und die Ergebnisse zu vergleichen.

Denn mit Fotos hast du einen Typen von Dateien verwendet für den windows die suche sehr optimiert hat (Musik, Bilder, Videos und Dokumentensuche geht bei windows sehr schnell da windows einen eigenen Such Cache anlegt für jeden dieser typen) Und ich gehe mal davon aus das windows beim directory scan einfach diesen suchcache verwendet, und daher so schnell ist

[mse]

Linux:
Als weiteres Gastsystem habe ich Kubuntu 14.04 LTS mit CoeTyphon 6.0 am Start.
Das selbe Beispielprogramm habe ich hier ebenfalls compiliert. Aus dem Gast heraus benötigt das Programm 1000 Sek., also ca. 20 mal solange.

Bist du sicher, dass das Problem der directory-scan ist? Mit MSEgui komme ich für 400'000 Dateien unter Linux auf knapp 8 Sekunden inklusive Darstellung im grid.

Code: Alles auswählen

 
procedure tmainfo.runev(const sender: TObject);
var
 ar1: filenamearty;
 t1: tdatetime;
begin
 t1:= nowutc();
 ar1:= searchfiles('',filenameed.value);
 filecountdisp.value:= length(ar1);
 grid.datacols[0].datalist.asarray:= ar1;
 timedisp.value:= (nowutc()-t1)*24*60*60;
end;
 

Vielleicht ist die Listbox mit 80'000 Einträgen überfordert?
EDIT:
application.processmessages() für jede Datei ist auch keine gute Idee.

[theo]

Das sehe ich auch wie mse.
Bevor du da eine Aussage über die Geschwindigkeit des File Scans machen kannst, musst du sämtliches GUI Zeug inkl. Processmessages rausschmeißen.

[Ralf]

Danke für Euer Feedback und die Anregungen.

Ich frage mich ja nur, warum Linux soviel langsamer als Windows ist.
Sind ja die selben Routinen, also auch ProcessMessages kommt in beiden Programmen vor.

Die Listbox wird ja auch unter beiden Betriebssystemen gefüllt und 80.000 Einträge finde ich nicht so dramatisch.
Das mit dem Caching Aspekt werde ich mal weiter verfolgen.... klingt plausibel.

Vielleicht fällt ja noch jemanden was ein?

Merci und viele Grüße,
Ralf

[Ralf]

Das sehe ich auch wie mse.
Bevor du da eine Aussage über die Geschwindigkeit des File Scans machen kannst, musst du sämtliches GUI Zeug inkl. Processmessages rausschmeißen.

Warum?
Ich habe es doch in beiden Versionen (Windows und Linux) drin?
Das erklärt doch nicht den Unterschied,oder übersehe ich was?

Das war übrigens am Anfang nicht drin (Processmessages), habe es eingebaut nachdem ich feststellte, wie lahm das unter Linux läuft, um den Status zu visualisieren.

Gruß,
Ralf

[wp_xyz]

Ich fülle testweise eine Listbox mit Zufallsstrings und komme nur allein damit zu einen ähnlichen Ergebnis: Für 10.000 Einträge messe ich unter Linux Mint 8 sec, für 20.000 35 sec. Windows 10 ist etwa einen faktor 5-10 schneller. Nachdem das offenbar quadratisch skaliert, werden 80.000 Strings schätzungsweise in 64*8 = 256 sec, etwa 4 min eingelesen werden.

Entferne ich das Listbox.Sorted := True for dem Einlesen und sortiere erst nachher, wird alles erheblich schneller. Und rasend schnell, 0.3 sec für 20.000 Einträge unter Mint, wird es, wenn ich die Strings zuerst in eine StringList schreibe und diese dann per Assign den Items der Listbox zuweise.

Ich denke daher, dass die unterschiedliche Implementierung des Sortierens der Listbox-Items zwischen gtk2 und Windows für die Unterschiede verantwortlich sind.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
const
  N = 20000;
var
  i, j: Integer;
  s: String;
  t: Integer;
  L: TStringList;
begin
  t := GetTickCount;
  L := TStringlist.Create;
  //Listbox1.Items.BeginUpdate;
  try
    L.Sorted := true;
//    Listbox1.Items.Clear;
//    Listbox1.Sorted := true;
    for i:= 1 to N do begin
      SetLength(s, random(10) + 3);
      for j:=1 to Length(s) do
        s[j] := char(Random(26) + ord('A'));
      L.Add(s);
//      Listbox1.Items.Add(s);
    end;
    Listbox1.Items.Assign(L);
  finally
    //Listbox1.Sorted := true;
//    Listbox1.Items.EndUpdate;
    Label1.Caption := IntToStr(GetTickCount - t) + 'ms';
    L.Free;
  end;
end;  

[mse]

Das sehe ich auch wie mse.
Bevor du da eine Aussage über die Geschwindigkeit des File Scans machen kannst, musst du sämtliches GUI Zeug inkl. Processmessages rausschmeißen.

Warum?
Ich habe es doch in beiden Versionen (Windows und Linux) drin?
Das erklärt doch nicht den Unterschied,oder übersehe ich was?

Du übersiehst, dass Lazarus auf Windows die z.B. Windows-Widgets und auf Linux z.B. GTK2 verwendet, welche komplett unterschiedleiche Verhalten zeigen können. Falls du das nicht möchtest, musst du ein Toolkit wie fpGUI oder MSEide+MSEgui verwenden, welche alles selber Zeichnen.
Übrigens, auch 52 Sekunden für einen Directory-Scan von 80000 Dateien finde ich sehr viel, bitte lies was wp_xyz schreibt.

[Ralf]

Das sehe ich auch wie mse.
Bevor du da eine Aussage über die Geschwindigkeit des File Scans machen kannst, musst du sämtliches GUI Zeug inkl. Processmessages rausschmeißen.

Das werde ich als nächstes Ausprobieren und den reinen Filescan betrachten.

[Ralf]

Nochmal vielen Dank für die Anregungen und Hinweise.
Die Unterschiede zw. Windows-GUI und GTK2 sind in der Tat gravierender als ich gedacht hätte.
Habe die Beispiele mal nachgebaut... und kann das im groben so bestätigen wie Ihr das darstellt.

Processmessages unter Windows ist natürlich auch nur zur Kontrolle gedacht, jedoch bei weiten nicht so dramatisch ausbremsend wie unter Linux, zumindest mit den Default Compilerschaltern...
Das mit der ListBox ist ebenso drastisch unterschiedlich in den beiden OS. Windows scheint das default besser (schneller) handeln zu können....

Da stellt sich mir natürlich auch die Frage, ob es was bringt, wenn ich mal QT4/5 oder GTK3 ausprobiere?
Oder wird dieser Aspekt davon unberührt bleiben?

Den reinen Filescan werde ich jedoch noch mal testen, denn das hat hat nix mit der GUI zu tun, wie Theo schon klar gestellt hat.

Auf jeden Fall bin ich schon wieder ein kleines bisschen schlauer geworden, Merci dafür

[Ralf]

Das sehe ich auch wie mse.
Bevor du da eine Aussage über die Geschwindigkeit des File Scans machen kannst, musst du sämtliches GUI Zeug inkl. Processmessages rausschmeißen.

Warum?
Ich habe es doch in beiden Versionen (Windows und Linux) drin?
Das erklärt doch nicht den Unterschied,oder übersehe ich was?

Du übersiehst, dass Lazarus auf Windows die z.B. Windows-Widgets und auf Linux z.B. GTK2 verwendet, welche komplett unterschiedleiche Verhalten zeigen können. Falls du das nicht möchtest, musst du ein Toolkit wie fpGUI oder MSEide+MSEgui verwenden, welche alles selber Zeichnen.
Übrigens, auch 52 Sekunden für einen Directory-Scan von 80000 Dateien finde ich sehr viel, bitte lies was wp_xyz schreibt.

Jetzt bin ich neugierig geworden, denn von fpGUI oder MSEide+MSEgui habe ich noch nichts gehört.
Wahrscheinlich wäre es jetzt eine blöde Frage zu fragen, ob das "besser", schneller und/oder komfortabler als Lazarus / CodeTyphon ist?

Ist die Installation einfach?
Dann würde ich das mal in einer neuen VM testen wollen.
Ist es unter Linux und Windows gleich gut oder gibt es Empfehlungen zu einem bestimmten OS?

Danke für's Feedback.

[mse]

Jetzt bin ich neugierig geworden, denn von fpGUI oder MSEide+MSEgui habe ich noch nichts gehört.

Für MSEide+MSEgui gibt es hier im Forum einen eigenen Bereich:
http://www.lazarusforum.de/viewforum.php?f=53

Wahrscheinlich wäre es jetzt eine blöde Frage zu fragen, ob das "besser", schneller und/oder komfortabler als Lazarus / CodeTyphon ist?

Ich bin der Autor von MSEide+MSEgui, für meine Zwecke ist es besser, schneller und komfortabler.

Ist die Installation einfach?

Ja, aus README.TXT:

Code: Alles auswählen

 
Installation:
*************
1. Download and install FPC 3.0.2, you can get it from 
   http://www.freepascal.org/download.var
2. Download mseide_msegui_src_4_4.zip and the mseide_* archive
   for your system.
   http://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.4/
3. Extract them to a directory of your choice ('yourdirectory') .
4. Run 'yourdirectory/bin/mseide' on linux and freebsed or 
   'yourdirectory\bin\mseide.exe' on windows.
5. In 'Settings'-'Configure MSEide'-'${MSEDIR}' select 'yourdirectory/msegui'.
6. In 'Project'-'Open' select 'yourdirectory/msegui/apps/demo/demo.prj'.
7. 'Target'-'Continue'.
 

Ist es unter Linux und Windows gleich gut oder gibt es Empfehlungen zu einem bestimmten OS?

MSEide+MSEgui hat konzeptbedingt in allen Umgebungen die gleichen Eigenschaften.
fpGUI ist hier:
http://fpgui.sourceforge.net/
MSEide+MSEgui ist umfangreicher und ausgereifter.

[mse]

Da stellt sich mir natürlich auch die Frage, ob es was bringt, wenn ich mal QT4/5 oder GTK3 ausprobiere?
Oder wird dieser Aspekt davon unberührt bleiben?

Den grössten Einfluss wird haben, die Empfehlungen von wp_xyz zu befolgen.

[Patito]

Übrigens, auch 52 Sekunden für einen Directory-Scan von 80000 Dateien finde ich sehr viel, bitte lies was wp_xyz schreibt.

Meiner Erfahrung nach ist die interne String-Verarbeitung bei solchen Dingen recht langsam.

Die rohe Zugriffszeit auf das FileSystem um aus 400000 Dateien 20000 interessante herauszusuchen
ist bei mir (Windows 10) hier 140 ms (Kaltstart) / 125 ms (Warmstart mit Cache).

Konvertiert man die Filenamen in z.B. UTF-8 (was eigentlich gar nicht geht, da die Konvertierung nicht verlustfrei ist)
und speichert das ganze ineffizient, liegt man schnell um den Faktor 100 daneben.

Konvertierst Du die Filenamen für MSE-IDE beim einlesen um? Und wenn ja: Wie genau?

[mse]

Konvertierst Du die Filenamen für MSE-IDE beim einlesen um? Und wenn ja: Wie genau?

Bei der Übernahme der Dateinamen in das MSEgui System wird auf Linux von utf-8 auf utf-16 gewandelt. Ungültige utf-8 Bytes werden in einem privaten Unicode-Bereich abgelegt und später beim Rückwandeln auf 8-Bit rekonstruiert. Die Funktion ist utf8tostring() von hier:
https://gitlab.com/mseide-msegui/mseide ... trings.pas
In Windows sind die Dateinamen ja bereits 16 Bit.