• Naslovna
• FAQ
• Pravilnik
• O ES-u
• Tim
• Korisnici
• Statistike

 

• elitesecurity ::
• elitemadzone ::
• EMAIL ::
• RSS ::
• ES Mobile

  Niste ulogovani?  Username :   Password:   

• Registracija
• Zaboravili ste password?
• Flashback ▲▼
• Login problem?

 

Pretraga:

 

Srodne teme 14.04.2024. Re: Gde je Kejt? (samo pogrešni odgovori) 15.11.2003. Izbacivanje dupliranih vrednosti jednog polja pri.. 03.02.2004. uporedjivanje nizova i dodavanje u niz 06.12.2004. Razliciti rezultati google pretrage na razlicitim.. 06.09.2005. Pretraga određene riječi u fajlovima i rezultat.. 27.09.2005. Google 7-mi rodjendan, i ponovo malo cirilice... 10.01.2006. Potrebne knjige iz Operacionih istrazivanja (opti.. 05.02.2006. Kako da uklonim sajt iz pretrage na Googlu? Navigacija Brisanje liste Aktuelne teme u ovom forumu: Koja je ovo veza izmedju klasa? oglasi.. Komspostiranje memorije SectorC: A C Compiler in 512 bytes Strangest sorting algorithm? Spisak ulica u Beogradu sa brojevima Kod koji daje neočekivani rezultat Najgori programski jezik svih vremena Your Favourite Programming Language LexAna - Level order parser ZFS commit ;) remove references to sla.. Dosli smo do kraja Murovog zakona, vre.. računanje sa datumima SoloLearn Free programming courses Kako u firefoxu da smanjim protok? Prelaz od C ka OO programiranju Izaberite forum: Linux Linux aplikacije Linux desktop okruženja Linux hardware Windows desktop Windows aplikacije Zaštita Office Windows drajveri Office :: Word Office :: Excel Macintosh Mac hardware Mac software Iphone Enterprise Networking SOHO Networking Wireless Windows mreže Linux mreže Wireless :: WiMax Wireless :: Mikrotik Wireless :: Wireless oprema Linux/UNIX serveri i servisi Unix BSD Skript jezici Security Virtualizacija Cloud Computing Services Security :: Kriptografija i enkripcija .NET 3D programiranje Art of Programming Asembler C/C++ programiranje Kernel i OS programiranje Pascal / Delphi / Kylix Java Embedded sistemi Perl PHP Python Visual Basic 6 Veštačka inteligencija Security Coding XML GameDev - Razvoj Igara Ostali programski jezici PHP :: PHP za početnike PHP :: Smarty template engine .NET :: .NET Desktop razvoj .NET :: ASP.NET .NET :: WPF Programiranje C/C++ programiranje :: C/C++ za početnike Baze podataka MySQL Oracle Access MS SQL Firebird/Interbase PostgreSQL Fiksna telefonija VoIP Udruženje korisnika teleko.. GSM - telefoni GSM - upotreba GSM - servisiranje Mreže i novosti Smartphone Mreže i novosti :: Mobilni internet Mreže i novosti :: Telenor - korisnički servis Mreže i novosti :: VIP - korisnički servis Mreže i novosti :: MTS - korisnički servis Smartphone :: Symbian OS Smartphone :: Windows Mobile Smartphone :: Android GSM - telefoni :: Nokia PDA Uređaji GPS Portable Players Anonimnost i privatnost ISP Browseri E-mail Instant Messaging FTP Google Hosting ISP :: Wireless mreže i ISP ISP :: ADSL E-mail :: Anti-spam Instant Messaging :: IRC Hosting :: Domeni Google :: Gmail E-Marketing Web aplikacije Web dizajn i CSS Web dizajn softver Web razvoj Pretraživači i SEO Flash Javascript i AJAX Web dizajn i CSS :: Kritike Grafički dizajn Izdavaštvo 3D modelovanje Rasterska grafika Vektorska grafika 3D modelovanje :: CAD/CAM Matične ploče, procesori .. Video karte i monitori Storage Ostali hardver Overclocking & Modding PC Konfiguracije Laptopovi Vodič za kupovinu - PC har.. Tablet PC Muzička produkcija Audio kompresija Audio softver Video produkcija Video kompresija Video softver Multimedijalni uređaji Digitalni fotoaparati Digitalne kamere Home Theater Digitalni fotoaparati :: Fotografija Digitalni fotoaparati :: Vodič za kupovinu - Digita.. Elektronika Elektrotehnika Elektronika :: TV uređaji Elektronika :: Radio elektronika i tehnika Elektronika :: Mikrokontroleri Elektronika :: Audio-elektronika Auto-elektronika :: Tuning Vodič za učenje Vodič za posao Vodič za emigraciju Fizika Matematika Nauka Sertifikati Informatika Vodič za učenje :: Seminarski radovi Vodič za učenje :: Obrazovne institucije Vodič za emigraciju :: Život u USA Vodič za emigraciju :: Život u Norveškoj Vodič za emigraciju :: Život u Nemačkoj E-Poslovanje E-Kupovina IT pravo i politika razvoja IT događaji IT berza poslova IS i ERP Ekonomija Berza Cryptocoins IT berza poslova :: Arhiva IT berze poslova IT pravo i politika razvoja :: Registar Nacionalnog ID E-Poslovanje :: E-Transakcije E-Poslovanje :: Forex E-Kupovina :: Platne kartice Digitalna Televizija Advocacy Ankete Predlozi i pitanja Vesti Čekaonica Vesti :: ES leto manifestacija MadZone TechZone Poljoprivreda AutoZone MotoZone Svakodnevnica Video igre MadZone :: Zanimljivi linkovi MadZone :: Kultura TechZone :: Ergonomija TechZone :: Grejanje TechZone :: Klimatizacija TechZone :: Bela tehnika AutoZone :: Fiat Panda club Lista poslednjih: 16, 32, 64, 128 poruka.

Mikky Član broj: 18 Poruke: 1563 217.26.67.* ICQ: 44582291 +58 Profil Optimizacija pretrage dupliranih fajova 31.08.2003. u 15:24 - pre 251 meseci Neznam sta se desilo sa tom temom na ovom forumu gde sam pitao kako napraviti program koji trazi duplirane fajlove po hard diskovima ali u svakom slucaju uradio sam ga i sad mi treba mala pomoc oko optimizacije. Dakle treba naci sve fajlove na hardu, ubaciti info o njima u memoriju i uporediti svaki sa svakim. To sam uradio preko resizable arraya, znaci prvo alociram memoriju recimo 10kb i nju popunjavam sa informacijama svakog fajla koga nadjem. Kad se ona popuni onda zovem funkciju koja prosiruje taj memorijski blok na jos 10kb i sve tako dok ima fajlova. Na kraju dobijem array sa informacijama o fajlovima, te informacije stavljam u moju strukturu koja sadrzi ime fajla, path, velicinu, atribute.. E sad dolazi uporedjivanje, za n fajlova ima n(n-1)/2 poredjenja, uzimam prvu strukturu u nizu i poredim je sa svakom sledecom, znaci pocinjem poredjenje od druge pa do kraja niza. Kad zavrsim sa prvom uzimam drugu i poredim je sa trecom i svakom sledecom do kraja niza itd.. Sve je to lepo ali provalio sam da je sporo, meni treba 10minuta da izvrsi sva poredjenja dok Windows commanderu za isti posao treba 2 minuta!!! Struktura izgleda otprilike ovako (MASM32 sintaksa): Code: FileInfo        struct     szFileName    db            MAX_PATH dup(?)            ; name of file     CreationTime    FILETIME        <?>                ; file's time of creation     ModifyTime    FILETIME        <?>                ; file's last write time       dwSize        dd            ?                ; file size                 dwAttributes    dd            ?                ; file attributes     FileInfo ends Znaci postoji niz ovakvih struktura, info o fajlovima ne ubacujem po nekom redosledu vec kako koji fajl nadjem (FindFirstFile/FindNextFile) tako ga ubacim. Pri poredjenju prvo poredim ove dword-ove, pa ako su isti onda stringove (filename) jer za to treba manje vremena nego da poredim prvo stringove. E sad, ja vise nemam ideja kako da ovo optimizujem dalje. I kad bi uspeo nesto sigurno ne bi dobio toliko poboljsanje na nivou windows commandera. -I know UNIX, PASCAL, C, FORTRAN, COBOL, and nineteen other high-tech words. Odgovor na temu

tOwk Danilo Šegan Zemun/Beograd Član broj: 94 Poruke: 2743 *.verat.net ICQ: 9344053 Sajt: alas.matf.bg.ac.yu/~mm011.. +2 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 15:45 - pre 251 meseci Pa što ne sortiraš listu jednom, i zatim porediš samo „susedne“? Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu. Odgovor na temu

filmil Filip Miletić Oce Technologies B.V., inženjer hardvera Arcen, NL Član broj: 243 Poruke: 2114 *.adsl.zonnet.nl Jabber: filmil@jabber.org ICQ: 36601391 +3 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 15:51 - pre 251 meseci Tvoja pretraga se svodi na problem sortiranja niza elemenata. Za sortiranje ti je potrebna funkcija poređenja (nazovimo je compare()) koja može da utvrdi da li se dve datoteke razlikuju ili ne. Pretpostavljam da imaš metod kako da utvrdiš da li su dve datoteke jednake ili različite jer umeš da porediš elemente. Teoretski rezultat kaže da mašina Fon Nojmanovog tipa (svi današnji računari), opremljena operacijom poređenja dva elementa niza ne može urediti elemente brže od . Poznat algoritam koji ume da uredi elemente niza u datom vremenu zove se Quick sort i izmislio ga je izvesni C. A. R. Hoare (ovo CAR jer je čovek zaista to :) ). Ideja je da urediš tvoje datoteke prema operaciji compare(), a koristeći Quick sort algoritam. Kako identični fajlovi imaju identične ključeve, u sortiranoj listi naći će se jedni do drugih. Zatim je potrebno proći kroz niz algoritmom unique koji komprimuje višestruke ulaze (odn. omogućava ti da saznaš koji fajlovi se ponavljaju) a koji se može odraditi u linearnom vremenu. Kako je pretraga diska takođe linearna u funkciji broja ulaza, ukupna složenost ovakvog algoritma bila bi a to je malo bolje od tvojih . f Odgovor na temu

-zombie- Tomica Jovanovic freelance programmer ni.ac.yu Član broj: 4128 Poruke: 3448 *.verat.net Sajt: localhost +5 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 16:07 - pre 251 meseci mislim da ću morati da se ne složim sa kolegama filipom i danilom. za ovakav posao je mnogo bolji hash algoritam. napraviš recimo 16tobitnu hash funkciju od podataka o fajlu, i ubacuješ u niz od 64k elemenata, gde je index niza taj 16tobitni hash. hash računaš recimo običnim xorovanjem dvobajtnih reči u fajl descriptoru (creation time, modification time, size i atributi su ti verovatno 32bitni brojevi, njih podeliš na po dve reči, i xoruješ. na kraju, xoruješ i po dva bajta iz naziva fajla. kad izračunaš hash_id jednog fajla, dodaš pokazivač na njegov file descriptor u niz na hash_id mestu hash_array[hash_id] ako se pri takvoj operaciji, ako već u tom mestu postoji već neki fajl, onda izvučeš njegove podatke preko pokazivača na file_info struct, i uporediš ta dva fajla. mrzi me da sad dokazujem, ali valjda ovaj algoritam teži (pri lepoj raspodeli/odabiru hash algoritma) komplexnosti O(n) (ovde konkretno za broj fajlova ispod milion.. za više, samo povećaš veličinu hash_id ključa...) blogče :: unescaped beta 　 » go-paste extenzija 　 » reč dana: backup 　 » bočne koalicije Odgovor na temu

filmil Filip Miletić Oce Technologies B.V., inženjer hardvera Arcen, NL Član broj: 243 Poruke: 2114 *.adsl.zonnet.nl Jabber: filmil@jabber.org ICQ: 36601391 +3 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 16:19 - pre 251 meseci Zombi, to je samo pod uslovom da je složenost umetanja u hash tabelu idealnih , ali to je moguće samo asimptotski -- ako je hash funkcija idealna, ako ravnomerno raspodeljuje fajlove u pojedine ćelije tabele, ako je tabela beskonačno velika i ako posle toga ne moraš da prolaziš kroz svaku pojedinačnu ćeliju, sortiraš i porediš -- a to ćeš morati da uradiš. E sad naravno mi govorimo o nekim slovima O -- ali kao što kažu uvek je bitna i ona implicitna konstanta. Može se desiti da tvoja ideja rezultuje u programu koji u nekim slučajevima radi brže. Ali niko ne može potvrditi da će to zaista da se desi. f Odgovor na temu

-zombie- Tomica Jovanovic freelance programmer ni.ac.yu Član broj: 4128 Poruke: 3448 *.verat.net Sajt: localhost +5 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 17:09 - pre 251 meseci hm.. da, zato sam i rekao "teži" pri nekim uslovima. a biću tako hrabar da tvrdim da će ovakav algoritam (za ovaj problem) uglavom dati bolje rezultate od bilo kog sort algoritma. a i btw, kad malo bolje razmislim, po čemu bi ste vi sortirali listu fajlova?!? po veličini? mislim da će mnogo veća gustina biti oko malih veličina fajlova, pa će i efikasnost quick sorta biti umanjena. dalje, još jedna prednost hash-a je što se on može puniti odma pri čitanju fajlova, znači ne mora dodatno da troši memoriju na posebnu listu file descriptora. (lično ne znam ni jedan sort algoritam koji može da iskoristi ovu prednost efikasno...) i generalno (u opštem slučaju), mislim da se uglavnom za nalaženje duplikata koristi hash algoritam, jer najčešće daje najbolje rezultate. inače miki, verovatno sam i malo preterao.. mislim da ti je za haš u ovom slučaju dovoljan (i brži/jednostavniji/bliži O(1) ;) i samo xor ecimo po dva (niža) bajta iz veličine i vremena kreiranja fajla.. i naravno, to radi odmah, pri nalaženju fajlova, nemoj prvo da ih trpaš u listu, pa da ih prebacuješ u hash mapu.... blogče :: unescaped beta 　 » go-paste extenzija 　 » reč dana: backup 　 » bočne koalicije Odgovor na temu

filmil Filip Miletić Oce Technologies B.V., inženjer hardvera Arcen, NL Član broj: 243 Poruke: 2114 *.adsl.zonnet.nl Jabber: filmil@jabber.org ICQ: 36601391 +3 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 18:39 - pre 251 meseci Sortiranje ne mora nužno da bude po veličini fajla. Dovoljno je da se recimo računa neka vrednost poput hash ključa i da se onda te vrednosti porede za dve datoteke. Sve identične kopije fajlova pritom će se naći jedna do druge. Ostale stvari poput umetanja u letu i slično su optimizacije drugog reda. Drugim rečima to je stavljanje tačke na i, neka prvo proradi sortiranje (to je principijelno poboljšanje) a kozmetika može doći i kasnije. f Odgovor na temu

leka Dejan Lekić senior software engineer, 3Developers Ltd. London, UK Član broj: 234 Poruke: 2534 *.telia.com Sajt: dejan.lekic.org +2 Profil Re: Optimizacija pretrage dupliranih fajova 31.08.2003. u 20:52 - pre 251 meseci Citat: tOwk: Pa što ne sortiraš listu jednom, i zatim porediš samo „susedne“? Danilo, to je tipično rešenje koje bi uradio UNIX administrator (verovatno) - sve fajlove na mašini strpao u fajl, propustio isti kroz sort, a onda kroz skript koji ispituje da li trenutna linija tog fajla odgovara sledećoj ... Prosto rešenje koje funkcioniše. Kad je u pitanju pisanje C aplikacije koja ovo radi, ja bih takođe koristio hash, s tim da bih ja "hash"-irao kompletno naziv fajla sa stazom (primer: /usr/local/share/ede/icons/efileman.png) . Dejan Lekic software engineer, MySQL/PgSQL DBA, sysadmin Odgovor na temu

tOwk Danilo Šegan Zemun/Beograd Član broj: 94 Poruke: 2743 *.verat.net ICQ: 9344053 Sajt: alas.matf.bg.ac.yu/~mm011.. +2 Profil Re: Optimizacija pretrage dupliranih fajova 01.09.2003. u 02:43 - pre 251 meseci Upotreba heša je potpuno ortogonalna na sortiranje — mogu se kombinovati potpuno nezavisno. Uostalom, ovo bi trebalo da donese znatno veće od petostrukog ubrzanja, ako je zaista nedostatak brzine bio izražen u tome. Dalje, radi se o podacima koji su već u memoriji, i ne znam zašto ti Leko pominješ neke fajlove, i ko zna šta? ;-) Koliko ja znam, standardni (ISO) C sadrži i jednu vrlo lepu funkciju za ovakve potrebe: qsort(). Sa tim podacima u memoriji, kako lepo pomenu Filip, potrebno je izvesti jedan quicksort. A Zombi, što se tiče toga da će biti mnogo više malih fajlova, ne vidim kakve to veze ima u proceni složenosti QuickSort algoritma? Prosto, za njega nije bitno da li imamo 10 hiljada fajlova koji se razlikuju po veličini za jedan bajt, ili 10 hiljada fajlova koji se razlikuju po veličini za 1MB, već je samo bitno u kakvom početnom poretku se nalaze ovi fajlovi. Mada, ne znam zašto je problem napraviti funkciju za poređenje koja poredi redosledom kakvim ti god želiš (tj. otkud ti ideja da bismo „mi“ sortirali prema veličini? možemo prema veličini, pa ako je ista prema datumu, pa ako je isti prema imenu, pa... — tako se to i inače radi :-P). Zatim, potrebno bi bilo izraditi dobru heš funkciju. Kako će sva vremena (vreme pravljenja, izmene, pristupa datoteci) biti u kratkom vremenskom periodu (2–3 godine u odnosu na opseg od 2 milijarde sekundi, ili oko 66 godina), to treba uzeti u obzir, a čini mi se da nijedan predlog to ne radi. Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu. Odgovor na temu

sspasic Sasa Spasic Član broj: 3261 Poruke: 175 *.medianis.net Jabber: sspasic@elitesecurity.org ICQ: 35454521 Profil Re: Optimizacija pretrage dupliranih fajova 01.09.2003. u 10:35 - pre 251 meseci Meni se cini da bi bila najbolja kombinacija sortiranja po velicini i hash funkcije, obzirom na to da se velicina fajla moze saznati samo citanjem informacije o fajlu koja je zapisana u direktorijumu, a za hash treba procitati i sadrzaj datoteke. Evo mog predloga: - Prvi deo 1. Procitas informacije o svim fajlovima (ime, velicina) 2. sortiras tu listu po velicini fajlova 3. prodjes kroz sortiranu listu i za sve grupe fajlova koji su po velicini jednaki ides na drugi deo - Drugi deo (svi fajlovi jednake velicine) 1. Procitas sve fajlove i odredis im MD5 (ili CRC ili nesto slicno) 2. iz MD5 odredis hash value (1..hash_table_size) 3. stavis informacije o fajlu u hash 4. Ako se u slotu hash tabele na istom mestu nalazi vec neki fajl, prvo uporedis MD5, pa tek ako se i to poklopi uporedjujes fajl bajt po bajt Odgovor na temu

chupcko Negde Beograd Član broj: 5560 Poruke: 1141 Sajt: www.google.com +63 Profil Re: Optimizacija pretrage dupliranih fajova 01.09.2003. u 16:03 - pre 251 meseci http://www.ioccc.org/1998/schweikh3.c Mozda ovo moze da pomogne, lepo je objasnjeno kako radi :)))) CHUPCKO Odgovor na temu

bOkIcA Bojan Abramovic Novi Sad Član broj: 1808 Poruke: 520 *.metrohive.net Sajt: www.bokica.com Profil Re: Optimizacija pretrage dupliranih fajova 01.09.2003. u 19:03 - pre 251 meseci Citat: leka: ...s tim da bih ja "hash"-irao kompletno naziv fajla sa stazom (primer: /usr/local/share/ede/icons/efileman.png) . Zar ne bi u ovom slucaju dobio dva razlicita rezultata hash-a? Odgovor na temu

Mikky Član broj: 18 Poruke: 1563 *.vdial.verat.net ICQ: 44582291 +58 Profil Re: Optimizacija pretrage dupliranih fajova 08.09.2003. u 22:38 - pre 251 meseci Ok, trebalo mi je malo (vise) vremena da demistifikujem sve vase postove posto nisam "skolovan" programer vec "divljak" :))))) Ima par problema, prvo velicina strukture tj velicina svakog elementa niza, koji opisuje fajl nije fiksne velicine. Ona zavisi od velicine imena fajla i velicine patha. npr c:\1\test.txt c:\blah\dummy\test.txt za ovaj prvi fajl bice potrebno manje memorije nego za drugi jer mu je path kraci. Da kazem da bi ovo mogao da sredim da mi svi elementi niza budu jednaki tako sto cu koristiti pointer na ime fajla umesto da smestam sam string u niz. znaci umesto Code: char szPath[velicina_stringa]; bilo bi Code: char *szPath; Samo nisam siguran da li je ovo potrebno da radim, da li ce mi biti lakse da uradim uporedjivanje i sortiranje ako su svi elementi niza jednake velicine? Druga stvar, u mom programu sam ostavio opciju da se fajlovi porede po onome sto user izabere... znaci on moze da izabere da li ce da poredi po velicini, vremenima, i imenu ali isto tako moze da izabere da se porede samo po imenu. Znaci u ovom drugom slucaju sortiranje niza po velicini bi bilo besmisleno jer velicina neigra nikakvu ulogu u poredjenju i trazenju duplikata. Takodje cu da ostavim opciju da se poredjenje po imenu vrsi kao case sensitive. U slucaju da nije case sensitive onda hasiranje imena fajla opet ne bi imalo smisla jer bi dobio dva razlicita hasha za iste fajlove npr "Test.txt" i "tEST.txt". (znaci program je za win32 gde fajlovi nisu casesensitive kao na unixu). Ovo cu jos da vidim kako cu da resim.. verovatno cu da na osnovu onoga sto je korisnik izabrao kao kriterijum za uporedjivanje odredim i kako cu da poredim. Npr ako izabere velicinu i modify time, onda cu da sortiram niz po velicini i sl. BTW koji od ova dva je efikasniji (brzi) nacin sortiranja niza u mom slucaju 1. Nadjem sve fajlove, pa uradim quicksort 2. Kako koji fajl nadjem ubacujem ga u niz i odmah sortiram (npr bubble sort) -I know UNIX, PASCAL, C, FORTRAN, COBOL, and nineteen other high-tech words. Odgovor na temu

Rapaic Rajko Bgd Član broj: 4105 Poruke: 810 *.pexim.co.yu +62 Profil Re: Optimizacija pretrage dupliranih fajova 10.09.2003. u 12:52 - pre 251 meseci Elem... 1) Prvi nacin je definitivno bolji, jer quicksort najbolje radi na nesortiranim podacima. 2) Zaboravi bubblesort u bilo kojoj varijanti; to je prevazidjen algoritam, i pominje se samo u udzbenicima. 3) Tebi treba varijanta quicksorta u kojoj prosledis Compare funkciju; na taj nacin sortiras kako zelis podatke. Pozdrav Rajko Odgovor na temu

Mikky Član broj: 18 Poruke: 1563 *.vdial.verat.net ICQ: 44582291 +58 Profil Re: Optimizacija pretrage dupliranih fajova 16.09.2003. u 23:46 - pre 251 meseci Evo cisto da se javim i zahvalim na pomoci, uspeo sam i rezultat je vise nego sto sam ocekivao. Znaci za onaj posao sto mi je prva rutini radila 10 minuta a Windows Commander za samo 2 minuta (znaci 5x brze), sad mi treba samo 1 sekund a mozda i manje, nisam tacno merio Znaci ubrzanje... 600 puta u odnosu na prvobitnu rutinu, odnosno 120 puta u odnosu na wincmd -I know UNIX, PASCAL, C, FORTRAN, COBOL, and nineteen other high-tech words. Odgovor na temu

tOwk Danilo Šegan Zemun/Beograd Član broj: 94 Poruke: 2743 *.verat.net ICQ: 9344053 Sajt: alas.matf.bg.ac.yu/~mm011.. +2 Profil Re: Optimizacija pretrage dupliranih fajova 17.09.2003. u 00:10 - pre 251 meseci Citat: Mikky: Znaci ubrzanje... A upotreba memorije (bar okvirno)? Bilo bi lepo i da kažeš šta ti je konkretno dalo najbolje rezultate (tj. najveće ubrzanje), kad su se već ljudi toliko trudili da ispišu gomilu mogućnosti ;-) Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu. Odgovor na temu

Mikky Član broj: 18 Poruke: 1563 *.vdial.verat.net ICQ: 44582291 +58 Profil Re: Optimizacija pretrage dupliranih fajova 17.09.2003. u 00:54 - pre 251 meseci Ok, znaci upotreba memorije na minimalnom nivou. Za svaki pronadjen fajl imam u memoriji po jednu onu strukturu (od cinimi se 7 dword-ova tj 28 bajtova) + full path string. U pocetku sam za svaki fajl uzimao struktura + MAX_PATH bajtova za skladistenje stringa sto je u 99% slucajeva bacanje resursa jer skoro ni jedan fajl (sa pathom) nema velicinu MAX_PATH (sto je cinimi se 260 bajtova). Dakle memoriju korisitm samo koliko je potrebno, ni bajt vise. A ubraznje je najvise postignuto tako sto prvo poredim samo fajlove po velicini, pa ako je to jednako onda poredim ostalo (ime, date/time..), tako da je to velika usteda. Pre toga samo koristio quicksort da sortiram niz po velicini fajlova, njemu treba recimo mozda 0.1 sekunda da sortirara taj niz od 100 hiljada clanova (svaki clan niza == ona struktura gore) Tako da dobijem jedne pored drugih clanove sa istim velicinama i tako ih poredim, cim naidjem na sledeci clan koji nema istu velicinu tu prekidam poredjenje i prelazim na sledeci fajl. Nisam pravio nikakve hashove, mislim da bi mi to samo usporilo celu akciju posebno ako je neki sloze algo tipa crc32. Naravno sve ovo uradjeno u asembleru, pokusao sam sto manje da koristim promenljive u memoriji a sto vise registre, mada ima jos malo mesta za optimizaciju ali to je moze se reci nebitno ako niste fanatik kao ja. Eh sad kad gledam wincmd mi je bas spor nesto, kod mene ni nevidis kad na dialogu proleti progress od 0 do 100% :) -I know UNIX, PASCAL, C, FORTRAN, COBOL, and nineteen other high-tech words. Odgovor na temu

Mikky Član broj: 18 Poruke: 1563 *.vdial.verat.net ICQ: 44582291 +58 Profil Re: Optimizacija pretrage dupliranih fajova 17.09.2003. u 01:30 - pre 251 meseci Evo za memoriju konkretno, u WinXp kada izvrsim pretragu na mom hardu od 80gb windows commanderom i mojim programom, windows task manager mi kaze Wincmd 30.9mb Moj program 18.6mb Ukupno ima 185.134 fajlova neracunajuci foldere. -I know UNIX, PASCAL, C, FORTRAN, COBOL, and nineteen other high-tech words. Odgovor na temu

Rapaic Rajko Bgd Član broj: 4105 Poruke: 810 *.pexim.co.yu +62 Profil Re: Optimizacija pretrage dupliranih fajova 17.09.2003. u 11:41 - pre 251 meseci Auh, svaka cast: quicksort + assembler! Mislim, radio sam sa quicksort-om u mnogo varijanti, ali mi je ipak zvucalo malo prebrzo: sort na 100000 clanova za 0.1 sekunde. A onda sam procitao da si pisao u assembleru... Evo ti i jedan hint kako da ubrzas stvar jos vise. Koristio si niz struktura (recorda) za podatke o fajlovima, je li tako? Shodno tome, swap (zamena) dva recorda u nizu ti radi sa kompletnim strukturama (kopira se po 28 bajtova). A da razmislis o nizu pointera na recorde? Na taj nacin ne bi swap-ovao kompletne recorde (ostaju u memoriji gde jesu), vec samo pointere na njih (recorde). Velicina pointera je 4 bajta... Pozdrav Rajko Odgovor na temu

-zombie- Tomica Jovanovic freelance programmer ni.ac.yu Član broj: 4128 Poruke: 3448 *.verat.net Sajt: localhost +5 Profil Re: Optimizacija pretrage dupliranih fajova 17.09.2003. u 17:47 - pre 251 meseci Citat: Mikky: Nisam pravio nikakve hashove, mislim da bi mi to samo usporilo celu akciju posebno ako je neki sloze algo tipa crc32. ma nema potrebe za crc32. mislim da sam ti već rekao da bi i jednostavni hash završio posao. ajde probaj ovo, umesto da sortiraš po veličini fajla, sortiraj po XORovanoj vrednosti veličine i vremena fajla (isto 4 bajta). taj jedan xor neće ništa usporiti program. i izmeri za nas i postuj dužinu trajanja drugog dela tvog programa (onaj koji prolazi taj niz i poredi članove). teoretski (a sigurno i praktično) drugi deo programa će biti mnogo brži jer ćeš imati vrlo malo (ako uopšte) fajlova sa istim hashom. blogče :: unescaped beta 　 » go-paste extenzija 　 » reč dana: backup 　 » bočne koalicije Odgovor na temu