Lumina-fm: Bitte einmel helfen und testen

SolarCatcher

Well-Known Member
Hallo,

KURZVERSION:
Wenn Du Lumina benutzt, probiere doch bitte einmal folgendes. Lege einige hundert (leere) Dateien in einem Verzeichnis an und schau, wie dann die Performance des Lumina File Managers ist - bei mir ist sie unterirdisch. Hier ein Skript mit dem Du 1500 leere Text-Dateien unter /tmp/testdir anlegen kannst:

Code:
#!/bin/sh
mkdir /tmp/testdir
i=1000
while [ $i -lt 2500 ]
do
    touch /tmp/testdir/$i.txt
    i=`expr $i + 1`
done;

HINTERGRUND:
ich nutze seit einem 3/4 Jahr den Lumina Desktop und bin recht zufrieden damit. Allerdings habe ich schon seit langem ein Performance Problem mit lumina-fm. In Verzeichnissen mit vielen Dateien braucht er schon für das Anzeigen mehrere Sekunden, eine Datei-Änderung (Umbennenen, Löschen) dauert dann sogar bis zu 50 Sekunden und fast nochmal so lange, bis der File Manager bei mir wieder benutzbar ist.

Ich habe seit einigen Tagen mit den Entwicklern versucht, den Fehler einzugrenzen - aber sie können es auf ihren Systemen nicht reproduzieren. Ich nutze Standard FreeBSD 11.0-RELEASE auf einem ca. 4 Jahre alten T530 mit i7 und 8GB RAM. Da darf eine Umbenennung einfach nicht mehrere Sekunden dauern. Auf der Command Line und im zum Vergleich einmal getesteten PCManFM (aus dem LXDE) geht es - wie man es erwarten würde - ruckzuck. Ich habe auch ein unverschlüsseltes UFS-Dateisystem ausprobiert (um auszuschließen, dass es mit dem geli-verschlüsselten ZFS zu tun hat) - aber dort das gleiche Problem.

Falls jemand einmal testen kann, wäre ich dankbar, wenn Ihr hier Eure Erfahrung zurückmelden könntet. Ich wüsste gerne, ob ich irgend ein seltsamer Einzelfall bin, oder ob andere auch das Problem haben. Das würde auch den Entwicklern helfen.
 
Kann ich bestätigen. Bei mir zeigen sich die gleichen Probleme.
11.0-RELEASE, i7 2700K, 16GB RAM, ZFS auf einer HDD.

[edit] im Terminal bekomme ich während z.B. dem Umbenennen von Dateien folgende Meldung: QCoreApplication::postEvent: Unexpected null receiver [/edit]
 
Danke, @sterum ! Das ist schon einmal sehr interessant - das dürft dann auch für (noch) mehr Aufmerksamkeit bei den Entwicklern sorgen.

Die Fehlermeldung, die Du siehst, sei lediglich "kostmetisch", hatten auch die Lumina-Entwickler an anderer Stelle gemeint.
 
Ich kann nicht beurteilen ob das nur kosmetischer Natur ist. Jedenfalls tritt während dem Umbenennen diese Meldung auf meinem System etwa 9000 Mal auf.

Klingt aber irgendwie nach "hätte man besser machen können ..."
So sehr ich die Idee hinter dem Lumina Projekt mag, aber dieses "hätte man besser machen können" zieht sich meiner Meinung nach durch das ganze Projekt.
 
Ich habe mir vor ein paar Tagen mal "lumina-1.2.0.p1,2 Lumina Desktop Environment" installiert und empfinde dasselbe Problem, was hier beschrieben wird.
Beim Öffnen eines Verzeichnisses mit "vielen" Dateien, kann ich mir in Ruhe eine Pfeife stopfen und beim Wechseln in ein ähnliches Verzeichnis anzünden ...
 
Nun gibt es

Code:
==> pkg info |grep lumina
lumina-1.3.0,3  Lumina Desktop Environment (meta-port)
lumina-archiver-1.3.0.p1  Archive manager from the Lumina Desktop
lumina-calculator-1.3.0.p1  Scientific calculator from the Lumina Desktop
lumina-core-1.3.0.p1  Lumina Desktop Environment
lumina-coreutils-1.3.0.p1  Lumina Desktop Environment
lumina-fileinfo-1.3.0.p1  File properties utility from the Lumina Desktop
lumina-fm-1.3.0.p1  Insight file manager from the Lumina Desktop
lumina-mediaplayer-1.3.0.p1  Streaming media player from the Lumina Desktop
lumina-screenshot-1.3.0.p1  Screenshot utility from the Lumina Desktop
lumina-textedit-1.3.0.p1  Plaintext editor from the Lumina Desktop
lumina-xdg-entry-1.3.0.p1  XDG desktop entry creator from the Lumina Desktop

und die Probleme sind nicht mehr vorhanden. Wo er vorher ewig brauchte, ist es jetzt flott beeinander.
 
und die Probleme sind nicht mehr vorhanden. Wo er vorher ewig brauchte, ist es jetzt flott beeinander.
Hier leider nicht. Habe gestern die lumina-1.3.0,3-pkg eingespielt und getestet, die im offiziellen Vierteljahres-Repo aufgetaucht sind... Ich habe den Eindruck, dass sich die Performance leicht verbessert hat. Aber in meinem Test-Ordner mit 1500 (leeren) Dateien dauert ein Umbenennen einer Datei immer noch ca. 20 Sekunden. Und dann nochmal 20 Sekunden, bevor Lumina-fm wieder etwas anderes machen kann.
 
Jetzt wollte ich das gerade noch einmal für Dich testen, habe aber wegen Synchronisationsproblemen mit meinen Clouds aktuell nur elementary OS im Laptop ... Sorry!
 
Sorry. Ich dachte, ich kann eine verfügbare zeit nutzen und es mal für dich testen, aber wie ich gerade sehe, ist es bei mir jetzt lumina-fm: 1.3.0. Ich habe nur den lumina-fm installiert (es gab noch zwei unerfüllte Abhängigkeiten zu irgendwas mit Qt5). Als Test habe ich genau nach dem Spript im Eingangsthread leere Dateien angelegt, lumina gestartet und ins Verzeichnis navigiert. Gleichzeitig habe ich das Verzeichnis mit pcmanfm geöffnet. Aus dem pcmanfm heraus dann eine Datei in leafpad geöffnet, geändert und abgespeichert. Dann in pcmanfm umbenannt.
In lumina-fm passierte nichts, die Datei stand noch immer mit ihrer alten Größenangabe und dem unveränderten Namen dort. Nach einer gefühlten halben Ewigkeit passierte dann ein update. Die Datei dann in lumina-fm umbenannt, erscheint sofort mit neuem Namen in pcmanfm, aber wieder erst nach einer halben Ewigkeit in lumina-fm.
lumina-fm das Fenster etwas größer gezogen: der Inhalt wird erst nach einer vollen Ewigkeit wieder passend dargestellt.

Ich würde für mich sagen: unbrauchbar.
 
Danke @pit234a !

"unbrauchbar" ist relativ - die Entwickler haben das auf div. Systemen und Konfigurationen getestet und können dieses Verhalten nicht reproduzieren. Es scheint nur einen kleinen Teil der User zu betreffen.

Sie haben schon angekündigt, dass sie das darunterliegende System zur Kommunikation mit dem Filesystem nochmal komplett umschreiben werden.
 
System: Toshiba Satellite A300
Code:
FreeBSD 11.1-RELEASE #0: Sun Oct  1 15:18:17 CEST 2017
  ich@laptop.localhost:/usr/obj/usr/src/sys/LAPTOP amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): text 80x25
CPU: Intel(R) Core(TM)2 Duo CPU  T6400  @ 2.00GHz (2000.11-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xc08e39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 4107427840 (3917 MB)

Das Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert eine Minute. Während dieser Zeit ist WCPU durchgehend bei 68–69%.
 
System: Asus Eee PC 1001PX
Code:
FreeBSD 11.1-RELEASE #1: Sun Sep  3 04:41:57 CEST 2017 
  ich@netbook.localhost:/usr/obj/usr/src/sys/NETBOOK i386 
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) 
VT(vga): text 80x25
CPU: Intel(R) Atom(TM) CPU N455  @ 1.66GHz (1666.52-MHz 686-class CPU) 
  Origin="GenuineIntel"  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10 
  Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> 
  Features2=0x40e39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE>
  AMD Features=0x20100000<NX,LM> 
  AMD Features2=0x1<LAHF> 
  TSC: P-state invariant, performance statistics 
real memory  = 2147483648 (2048 MB) 
avail memory = 2085056512 (1988 MB)

Das Löschen und Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert jeweils zwei Minuten. Während dieser Zeit ist WCPU bei beiden Operationen jeweils durchgehend bei 76–77%.
 
Zuletzt bearbeitet:
System: Lenovo ThinkCentre M58p
Code:
FreeBSD 11.1-STABLE #8 r322509M: Mon Aug 14 23:22:28 CEST 2017
  ich@riara.uni.cx:/usr/obj/usr/src/sys/RIARA amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): text 80x25
CPU: Intel(R) Core(TM)2 Duo CPU  E8400  @ 3.00GHz (2992.56-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xc08e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7748583424 (7389 MB)

Das Löschen und Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert jeweils 33 Sekunden. Während dieser Zeit ist WCPU bei beiden Operationen jeweils durchgehend bei etwa 70%.
 
Sagt der Entwickler!

Änderungen an einer Datei sind jetzt wirklich so schnell, wie man es erwarten würde - keine merkliche Verzögerung!

Aber - zumindest auf meinem FreeBSD 11.1-RELEASE Laptop ist das Problem nur verschoben: Während das erste Öffnen des Test-Ordners recht flott ging, dauert es jetzt geschlagene 15 Sekunden. Damit bleibt Lumina für mich weiterhin ein Test-Spielzeug und nichts, was ich täglich einsetzen werde.

Wobei ich die Hoffnung habe, dass die Entwickler es hinbekommen werden, dass sowohl das Öffnen eines Ordners als auch das anschließende Arbeiten darin, einigermaßen flott funktionieren. Zumindest scheinen sie endlich die Stellschrauben gefunden zu haben, die dieses Verhalten für einige von uns unerträglich macht.
 
Das neue Jahr brachte ein neues Quarterly Repo und damit lumina-1.4.1,3. Ich hab's nach einiger Abstinenz mal wieder getestet und bin hocherfreut festzustellen, dass die Performance-Probleme mit dem Lumina File Manager (aka Insight) der Vergangenheit angehören - sowohl auf meinem Hauptlaptop (FreeBSD 11.1-RELEASE) als auch auf meinem Zweitlaptop (HardenedBSD 11-STABLE). Ich versuche jetzt also wieder, ob Lumina als mein primäres Desktop Environment taugen könnte...
 
Zurück
Oben