zipfldr.dll na WinXP SP3 a vytížení procesoru

[zarevak]

Dobrý den,
pokud přejdu v Salamanderu do složky s několika velmi velkými ZIP soubory (10GB v 20-ti souborech; některé velikosti 2GB), tak Salamander vytíží procesor na 100%.

Pokud se v Process Exploreru podívám na zásobník pracujícího vlákna, tak je zde k vidění zipfldr.dll (6.00.2900.5512 (xpsp.080413-2105)):

Code: Select all

ntkrnlpa.exe+0x6a7bf
ntkrnlpa.exe!PsDereferencePrimaryToken+0x362
ntkrnlpa.exe!KiDeliverApc+0xb3
hal.dll+0x2c35
zipfldr.dll+0x101bd
zipfldr.dll+0x102a0
zipfldr.dll+0xab8f
zipfldr.dll+0x7c6e
zipfldr.dll+0x8177
SHELL32.dll!SHGetMalloc+0x3d03
SHELL32.dll!SHCreateQueryCancelAutoPlayMoniker+0xa11e
SHELL32.dll!SHGetFileInfoW+0xdc
SHELL32.dll!SHGetFileInfoA+0x6e
salamand.exe+0xe3a62
salamand.exe+0xe3b06
salamand.exe+0x42034
salamand.exe+0x42a41
salamand.exe+0x42aae
SALRTL.DLL!beginthreadex+0xca
kernel32.dll!GetModuleFileNameA+0x1b4

Je možné se tohoto nějakým způsobem zbavit? (vlákno pracuje i chvíli po opuštění složky - asi do dokončení práce s aktuálně otevřeným ZIPem)

[Jan Rysavy]

Jak se ve stejné situaci chová Windows Explorer, dojde také k zátěži CPU?

Jak se Salamander chová při zapnutém Options > Configuration > Drives > Fixed drives > Use simple icons?

(vlákno pracuje i chvíli po opuštění složky - asi do dokončení práce s aktuálně otevřeným ZIPem)

Obecně vlákna, která se nám nevrátila po volání Win API, necháváme na pozadí "vyhnít" ve speciálních frontách místo jejich zabíjení. Při zabití je slušná šance, že vlákno bude ve vnitřní kritické sekci Windows a následně přestanou fungovat zdánlivě nesouvisející části Salamandera (po volání API se bude systém snažit vstoupit do "zakouslé" kritické sekce).

[zarevak]

Windows Explorer - ani ťuk na procesoru. Mám nainstalovaný WinRAR, takže ikonky i asociace patří jemu.

Simple Icons - taky ani ťuk na procesoru.

Salamander z nějakého důvodu využije zipfldr.dll aniž by ho potřeboval. Navíc protože ZIP soubory mám v Salamanderu asociované k ZIP pluginu, tak nevidím ani WinRAR ikonky, ale Salamandeří zástupné archivní ikonky.

Chápu chování Salamandera a vyhnívajícími vlákny, ale myslím, že by v tomto případě nemělo vlákno pracovat vůbec.

Jen tak mimochodem: Explorer nikdy zipfldr.dll ani nenačte. Salamander ho načte při vstupu do této složky (po čistém spuštění)

Další testování: Chyba souvisí s TortoiseSVN (1.5.6, Build 14908 - 32 Bit , 2008/12/20 11:51:04) - pokud vypnu jeho overlay ikonky, tak problém zmizí. V Exploreru se však tento problém neobjevuje.

EDIT: složka není verzovaná - žádné Tortoise ikonky se v té době v Salamanderu ani v jednom panelu nezobrazují

[Jan Rysavy]

Poznámka: to by mohlo souviset s vláknem http://forum.altap.cz/viewtopic.php?t=2899

[Jan Rysavy]

Další testování: Chyba souvisí s TortoiseSVN (1.5.6, Build 14908 - 32 Bit , 2008/12/20 11:51:04) - pokud vypnu jeho overlay ikonky, tak problém zmizí. V Exploreru se však tento problém neobjevuje.

Vypnuto na straně TSVN nebo na straně Salamandera?
(Options > Configuration > Icon Overlays > Display custom icon overlays)

[zarevak]

Vypnuto na straně TSVN nebo na straně Salamandera?
(Options > Configuration > Icon Overlays > Display custom icon overlays)

Vypnuto v Salamanderu a musí být vypnuty všechny TortoiseSVN overlay ikonky - v TSVN se mi v rychlosti nepodařilo najít "vypínač".

Ještě drobnost k těm ZIP souborům - obsahují několik tisíc souborů. Ten největší (2GB) obsahuje 15 447 souborů ve 490 složkách - rozbalené 3,4GB.

Načtení této problematické složky s vypnutýmy TortoiseSVN ikonkami trvá procesoru cca 0.05 sekund. Načtení (dokud se neuklidní vytížení procesoru - soubory jsou zobrazeny okamžitě včetně ikon) stejné složky se zapnutými ikonkami trvá mému procesoru 105 sekund! (CPU Time - pozorovaný čas je o fous delší)

Dále je zajímavé, že není využit proces TSVNCache.exe, který naopak maká ve verzovaných složkách.

Pokud během této "práce" hledím do Process Exploreru na hodnoty I/O Read Bytes a I/O Other Bytes, tak obě stoupají přibližně stejným a pomalým tempem. I/O Read Bytes se zastaví na 13MB. I/O Other Bytes se zastaví na 17MB. Soubory jsou postupně otevírány (viděno v panelu "Handles") na velmi krátkou dobu - procesor pracuje dále i po jejich zavření.

Poznámka: právě jsem našel jeden 600MB velký ZIP s 27 700 soubory, který tento problém způsobí také i když je ve složce sám (30sec CPU Time). Pokusím se vytvořit nějaký testovací ZIP nebo zaslat tento....

[zarevak]

Tak jsem pro vás vyrobil malý ZIP soubor s 46 656 soubory, který mému procesoru zabere 135 sekund CPU Time.

Ke stažení: http://temp.zarevak.net/filetest.zip (5,78MB, rozbalený: Data: 230Kb - Size on disk: 182MB)

[Jan Rysavy]

Díky za informace a testy. Problém jsem odstranili. Příčinou je chyba v MSDN, kterou jsem právě nahlásil: http://msdn.microsoft.com/en-us/library ... S.85).aspx

Zbytečné volání IShellFolder::GetAttributesOf() způsobovalo ono zamrzání. Windows Explorer metodu nevolá, protože skutečně potřebné atributy pro IsMemberOf() jsou součástí listingu adresáře (viz WIN32_FIND_DATA::dwFileAttributes).

[zarevak]

Díky!

Snad to vyřeší i další výtuhy (někdy jsem pozoroval po dokončeném kopírování, ale nejsem schopen si vybavit detaily (možná také bylo spojeno se ZIPy) - kdyžtak se ozvu)

[Jan Rysavy]

Celkově nám ožilo získávání Overlay Icons. Volání GetAttributesOf() bylo zavedeno od AS 2.51, protože uživatelé hlásili problém se shazováním offline atributu u adresářů. Verze 2.50 posílala do IsMemberOf metody dwAttrib == 0.