Altap Salamander Support Forums

Ahoj,

neslo by udelat by neco udelat s operaci listovani, ktera se deja pred kazdou akci (kopirovani, presun, ...)? Pri 3GB zdrojaku je to na nekolik minut (a okno SS je tuhe).

Obecne bych videl 2 moznosti (videl bych jich vice, ale na to nemate cas):
1) Toto listovani presunout okamzite po startu do separatniho threadu.
2) Listovani provadet "jakmile narazim na slozku" pri postupu.

Jde tedy o klasické načtení obsahu adresáře (žádný plugin)?
Pevný disk nebo síťový?
Kolik souborů máš takto na jedné hromadě?

Jan Rysavy wrote:Jde tedy o klasické načtení obsahu adresáře (žádný plugin)?
Pevný disk nebo síťový?
Kolik souborů máš takto na jedné hromadě?

Je to lokalni, IDE disk. Je tam asi 40 tis. souboru. Jde o klasicke nacteni - to co se deje pred fyzickym kopirovanim/presunem/...

Původně jsem se domníval, že se jedná o čas potřebný k vylistování adresáře po vstupu do něj nebo po příkazu Refresh, ale nyní mám dojem, že se ti jedná o stavbu stromu před operací.

Pokud jde o listování adresáře obsahujícího 50000 souborů, zkusil jsem naměřit časy pro Windows Explorer, FAR 1.70 beta 5, Total Commander 6.53 a Servant Salamander 2.5 beta 10.



Optimalizaci těchto kritických oblastí se průběžně věnujeme, například Servant Salamander 2.0 byl při mazání velkého počtu souborů mnohem pomalejší proti současné verzi 2.5.

Na problém stavby stromu se Petr podívá do kódu a dá vědět. Jak přibližně vypadá adresářová struktura toho 3GB stromu? (V kolika adresářích je těch 40000 souborů rozmístěno?)

Jan Rysavy wrote:Optimalizaci těchto kritických oblastí se průběžně věnujeme, například Servant Salamander 2.0 byl při mazání velkého počtu souborů mnohem pomalejší proti současné verzi 2.5.

Jenze casem narazite, tak jako tak - az bude mit nekdo 100 tisic souboru treba. Bylo by dobre na tom zapracovat i navrhove (napr. to zminovane vlakno) ne jen optimalizacne. A zrovna to vlakno mi pripada jako nekonfliktni reseni oproti predchozi idee navrhu.

Jan Rysavy wrote: Na problém stavby stromu se Petr podívá do kódu a dá vědět. Jak přibližně vypadá adresářová struktura toho 3GB stromu? (V kolika adresářích je těch 40000 souborů rozmístěno?)

V asi 2000-2500 adresarich.

cincura.net wrote:Jenze casem narazite, tak jako tak - az bude mit nekdo 100 tisic souboru treba. Bylo by dobre na tom zapracovat i navrhove (napr. to zminovane vlakno) ne jen optimalizacne. A zrovna to vlakno mi pripada jako nekonfliktni reseni oproti predchozi idee navrhu.

Nic takového neplánujeme. Se současným výkonem jsme velmi spokojeni, viz porovnání nahoře. Jádro Salamandera naprosto není připravené na zavedení načítání adresáře na pozadí a implementace by si vzala dlouhé měsíce práce. Přinos by byl minimální, kolik běžných uživatelů často otevírá adresář obsahjící desítky tisíc souborů?

Jan Rysavy wrote:Přinos by byl minimální, kolik běžných uživatelů často otevírá adresář obsahjící desítky tisíc souborů?

Nejde o otevirani. Ale o to dlouhe listovani pred zacatkem kopirovani. Ktere pokud zapocitam do casu cele operace znacne toto prodluzuje.

Nerikam, ze thread byl jedinym resenim. Muze se prece prijit struktura pri kopirovani (live - jakmile narazim na slozku, zacnu ji kopirovat a zanoruju se dal. V konecnem case tot musi skoncit.)

A diky tomu, ze se to deje live to nebude tolik zdrzovat
- pokud to bude jedna slozka -> stejny problem jako predtim, OK nevadi.
- pokud je to vic slozek, rychlost (z pohledu jak to "jede") je vyssi.

Pokud jde o vykon, urcite je super. Ale my tu mluvime o vylepseni, ne hrubem vykonu. Je rozdil BruteForce oproti inteligenci.

cincura.net wrote:Nejde o otevirani.

Psal jsem právě o otevírání adresáře, asi to není z textu jasné.

Ohledně stavby stromu před operací: naměř nám prosím na tom rozlehlém stromě, kolik času si vezme příkaz Commands > Calculate Directory Sizes (dvakrát za sebou) a kolik času si vezme příprava pro operaci (například před příkazem Copy). Můžeš mi poslat stejný srovnávací graf ze Správce úloh, jako je vidět nahoře? Jde o to, že na našich počítačích stavba stromu sice trvá několik vteřin, ale ne minuty, jako u tebe. Pošli případně také fotku toho napočítaného Calculate Directory Sizes okna. Jde o NTFS partici? Díky.

cincura.net wrote:Nejde o otevirani. Ale o to dlouhe listovani pred zacatkem kopirovani. Ktere pokud zapocitam do casu cele operace znacne toto prodluzuje.

Tohle je nesmysl - vzdycky je potreba zjistit co se ma kopirovat, a je celkem fuk jestli to delas najednou na zacatku (coz je myslim casove vyhodnejsi) nebo opakovane vzdy kdyz jdes na dalsi soubor.

Ted jsem presouval 34000 souboru ve 3500 adresarich, priprava operace trvala presne 30 vterin, operace samotna vypada, ze bude trvat cca 50 minut (je to 90GB).

Chapu, ze to cekani na zacatku operace obtezuje, ale presun do threadu sebou nese spoustu komplikaci s ovladanim (pri chybe by uzivatel prisel o oznaceni, atd.). Zaver: v soucasne chvili to nepovazujeme za rozumny.

Petr Solin wrote: Tohle je nesmysl - vzdycky je potreba zjistit co se ma kopirovat, a je celkem fuk jestli to delas najednou na zacatku (coz je myslim casove vyhodnejsi) nebo opakovane vzdy kdyz jdes na dalsi soubor.

Casove to samozrejme vyjde na stejno (technicky vzato). Ovsem na zacatku me to zdrzuje v dalsim pouzivani.

Petr Solin wrote: Ted jsem presouval 34000 souboru ve 3500 adresarich, priprava operace trvala presne 30 vterin, operace samotna vypada, ze bude trvat cca 50 minut (je to 90GB).

Ja mam ted po ruce jen notebook, 23 000 souboru, 47 sekund (notebookovej disk je jasne pomalejsi). Asi jsem postizenej tim programovanim, me to proste vadi.

Petr Solin wrote:Zaver: v soucasne chvili to nepovazujeme za rozumny.

Jasny, vy jste tu vyvojari.

Petr Solin wrote:vzdycky je potreba zjistit co se ma kopirovat, a je celkem fuk jestli to delas najednou na zacatku (coz je myslim casove vyhodnejsi) nebo opakovane vzdy kdyz jdes na dalsi soubor.

Až doteď jsem předpokládal, že úvodní načtení stromu je zde jen kvůli zjištění přibližné celkové délky a soubory se kopírují až které se najdou právě v okamžiku kopírování adresáře. Hned jsem udělal pár pokusů. A výsledek - Salamander i Windows Explorer si nejprve načtou seznam a dle něj pak kopírují. A zřejmě jen díky přirozené opatrnosti jsem zatím nepřišel o nová data. Far ani Total Commander nepoužívám, netestoval jsem.

Při takovémto způsobu kopírování je (při dostatku paměti) zřejmě časově výhodnější nejprve načíst strom a pak kopírovat (ačkoli to bude záležet na filesystemu, jestli si stejně nemusí znovu najít directory entry (např. FAT, aby našel počáteční sector)). Nicméně odhaduji, že toto máte dostatečně protestované.

Takže pokud už dělat nějaké úpravy, tak v tom smyslu, aby se zkopírovaly i soubory nově vytvořené po začátku delšího kopírování - nebo na takové soubory upozornit obdobně, jako upozorňujete na soubory které byly smazány/přejmenovány po začátku kopírování. Tedy "listovat" (také/jenom) v době kopírování.

Datalog wrote:A zřejmě jen díky přirozené opatrnosti jsem zatím nepřišel o nová data

Nerozumím, můžete to prosím rozvést? Děláte snad to, že označíte zdrojový adresář, začnete ho kopírovat jinam a potom rychle (dokud operace probíhá) začnete tento adresář měnit? Pokud byste například v takovém adresáři vytvořil nový soubor, ten se již nepřekopíruje.

Tedy "listovat" (také/jenom) v době kopírování.

Salamander od svého počátku funguje tak, že v první fázi načte kompletní adresářovou strukturu a uloží ji do operačního skriptu. Během druhého kroku tento skript prochází a vykonává vlastní operace (kopírování, přesun, mazání, atd). Naši uživatelé jsou s tímto pojetím spokojeni, takže nevidíme důvod na něm něco měnit.

Samozřejmě je nám jasné, že možných řešení je celá řada...

Jan Rysavy wrote:Naši uživatelé jsou s tímto pojetím spokojeni, takže nevidíme důvod na něm něco měnit.

Samozřejmě je nám jasné, že možných řešení je celá řada...

Nekteri s tim spokojeni nejsou. Uz jsme 2.

Ale chapu, ze nezvladate tyto veci delat.

Jan Rysavy wrote:

Datalog wrote:A zřejmě jen díky přirozené opatrnosti jsem zatím nepřišel o nová data

Nerozumím, můžete to prosím rozvést? Děláte snad to, že označíte zdrojový adresář, začnete ho kopírovat jinam a potom rychle (dokud operace probíhá) začnete tento adresář měnit? Pokud byste například v takovém adresáři vytvořil nový soubor, ten se již nepřekopíruje.

Ano, přesně takovou operaci jsem měl na mysli - dám kopírovat celý delší strom s větším objemem dat a občas ještě kontroluji a případně měním (typicky třeba datum z exif) souborů co se kopírují až na konci. Naštěstí změna atributů či obsahu souboru není problém - potíže by nastaly pouze pokud bych vytvořil nový soubor a to nedělám. Pochopitlně bych mohl kopírovat "po kouskách", ale zdržuje to a člověk se musí hlídat co už nakopíroval (obzvláště když se kopií přepisují starší věci).

Ale jak z vlastní praxe vidím, současný stav je asi vyhovující, jsem opatrný co dělám. Jen jsem se dost polekal že to funguje trochu jinak než předpokládám, a pak zase uklidnil, protože mi to dokonce i přes jiné chování než jsem předpokládal zatím nikdy nezpůsobilo problém (nebo jsem si toho nevšimnul, pak to ale nebylo až tak důležité).

cincura.net wrote:Nekteri s tim spokojeni nejsou. Uz jsme 2.

Měl jsem na mysli většinu našich uživatelů, jejichž nejfrekventovanější požadavky jsou shrnuty v ALTAP Roadmap.

Pokud se situace změní a o doposud okrajově požadovanou vlastnost (například přesunutí stavby operačního skriptu na pozadí) si začnou psát desítky uživatelů, pravděpodobně priority přehodnotíme. Samozřejmě je ve hře mnoho dalších faktorů (pouze časté žádosti nestačí):

• Není změna víc na škodu než k užitku?
  Zapadá změna do celkové koncepce Salamandera?
  Dokážeme ji uspokojivě a v konečné čase naprogramovat?
  Má požadovanou vlastnost naše konkurence? Jak se tam osvědčila?
  atd.