---

Da jeg står og skal finde en post i en database fra mit program, vil jeg
gerne høre om der er nogen der ved hvad der er hurtigst:
1. At åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller
2. At søge i en database (med samme antal poster) efter alle poster hvor id
= 172
3. Opdele databasen i undertabeller, hvor tabel 1 indeholder 1-1000, tabel
2: 1001-2000 osv. Hvad er da det optimale antal poster pr. tabel?

Håber der er nogen der har erfaring med det.

---
Mads Chr. Olesen
MadsChrO@Yahoo.com

---

"Mads Chr. Olesen" <MadsChrO@Yahoo.com> skrev i en meddelelse
news:9gqfbv$bbb$1@news.inet.tele.dk...
> Da jeg står og skal finde en post i en database fra mit program, vil jeg
> gerne høre om der er nogen der ved hvad der er hurtigst:
> 1. At åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller
> 2. At søge i en database (med samme antal poster) efter alle poster hvor
id
> = 172
> 3. Opdele databasen i undertabeller, hvor tabel 1 indeholder 1-1000, tabel
> 2: 1001-2000 osv. Hvad er da det optimale antal poster pr. tabel?

Det kommer ved an på database typen (Access, MySQL, SQLServer Oracel osv.)
hvor stor den er osv. men det må være hurtiger men en database end at åbne
en fil.

Men hvis man skal lave et program der skal køre hurtig skal det nok ikke
være i VB. Dermed mener jeg ikke at VB ikke er hurtig men at VC++ f.eks. er
meget hurtiger.

Sony

---

Sony <playstation@nintendo.dc> wrote in message
news:9gqgni$gsr$1@news.inet.tele.dk...
> "Mads Chr. Olesen" <MadsChrO@Yahoo.com> skrev i en meddelelse
> news:9gqfbv$bbb$1@news.inet.tele.dk...
> > Da jeg står og skal finde en post i en database fra mit program, vil jeg
> > gerne høre om der er nogen der ved hvad der er hurtigst:
> > 1. At åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller
> > 2. At søge i en database (med samme antal poster) efter alle poster hvor
> id
> > = 172
> > 3. Opdele databasen i undertabeller, hvor tabel 1 indeholder 1-1000,
tabel
> > 2: 1001-2000 osv. Hvad er da det optimale antal poster pr. tabel?
>
> Det kommer ved an på database typen (Access, MySQL, SQLServer Oracel osv.)
> hvor stor den er osv. men det må være hurtiger men en database end at åbne
> en fil.
>
> Men hvis man skal lave et program der skal køre hurtig skal det nok ikke
> være i VB. Dermed mener jeg ikke at VB ikke er hurtig men at VC++ f.eks.
er
> meget hurtiger.
>
> Sony

Hvis der vælges en databaseløsning (hvad jeg klart vil anbefale), så tror
jeg ikke der vil nogen nævneværdig forskel i hastighed på et C eller et VB
program da det meste alligevel håndteres af databasedriveren.
--
Bjørn

---

> Hvis der vælges en databaseløsning (hvad jeg klart vil anbefale), så tror
> jeg ikke der vil nogen nævneværdig forskel i hastighed på et C eller et VB
> program da det meste alligevel håndteres af databasedriveren.
> --
> Bjørn
Yep du har ret i det jeg mente var også bare at generelt at hvis hastihed er
vigtig er VB ikke så hurtig som andre sprog.

---

"Sony" <playstation@nintendo.dc> skrev i en meddelelse
news:9gr04g$r69$1@news.inet.tele.dk...
> > Hvis der vælges en databaseløsning (hvad jeg klart vil anbefale), så
tror
> > jeg ikke der vil nogen nævneværdig forskel i hastighed på et C eller et
VB
> > program da det meste alligevel håndteres af databasedriveren.
> > --
> > Bjørn
> Yep du har ret i det jeg mente var også bare at generelt at hvis hastihed
er
> vigtig er VB ikke så hurtig som andre sprog.
>
Mener du hastigheden i udviklingen, eller ekskveringshastigheden?

mvh
Anton

---

> Mener du hastigheden i udviklingen, eller ekskveringshastigheden?
>
> mvh
> Anton
Jeg viste jeg ikke skulle have haft skrevet det indlæg Hvad tror du
selv? Ekskeringshastigheden men det har sansynligvis nogen betyding på de PC
vi alle køre med i dag med mindre - som jeg også skriver- at det er meget
vigtigt at ens program køre meget hurtigt.

Sony

---

Det var også det jeg gættede!
Men jeg forstår ikke helt at C skulle være så meget hurtigere end VB.
I bund og grund sker der jo det samme i bege sprog. Det er de samme
API'er der bruges.
Jeg tænker på vores små applikationer til at opdatere en db osv.
Jeg kan godt se at hvis man skal lave noget grafik (spil), kan man nok
opnå en del med C (C++). Men mon så ikke man burde tage skridtet
fuldt ud (Asm).
Hvis jeg laver noget i C er det ikke på grund af hastigheden, men på grund
af
flere tråde (og det er meget træls VB ikke har det!) og den delvise
portabilitet.
For lige at vende tilbage til hastigheden på VB.
Jeg er klar over at i VB3 - 4 -5 var der stor forskel, medens forskellen i
VB6 var/er noget mindre.
Desværre har jeg ikke været i stand til at finde noget dokumentation til at
underbygge det, omvendt har
jeg heller ikke kunnet finde noget dokumentation på det modsatte.

mvh
Anton

"Sony" <playstation@nintendo.dc> skrev i en meddelelse
news:ukhY6.818$MT.66844@news000.worldonline.dk...
> > Mener du hastigheden i udviklingen, eller ekskveringshastigheden?
> >
> > mvh
> > Anton
> Jeg viste jeg ikke skulle have haft skrevet det indlæg Hvad tror du
> selv? Ekskeringshastigheden men det har sansynligvis nogen betyding på de
PC
> vi alle køre med i dag med mindre - som jeg også skriver- at det er meget
> vigtigt at ens program køre meget hurtigt.
>
> Sony
>
>

---

Anton Vestergaard wrote:

> Hvis jeg laver noget i C er det ikke på grund af hastigheden, men på grund
> af
> flere tråde (og det er meget træls VB ikke har det!)

Det har været muligt at multithreade i Visual Basic siden version 5. Jeg
har så sent som idag brugt multithreading til at løse et problem med VB
på mit arbejde.
Med venlig hilsen
Lars

---

Hvordan?

/Anton
"Lars Hoffmann" <larshoffmann@teleline.es> skrev i en meddelelse
news:3B327049.1318F794@teleline.es...
> Anton Vestergaard wrote:
>
> > Hvis jeg laver noget i C er det ikke på grund af hastigheden, men på
grund
> > af
> > flere tråde (og det er meget træls VB ikke har det!)
>
> Det har været muligt at multithreade i Visual Basic siden version 5. Jeg
> har så sent som idag brugt multithreading til at løse et problem med VB
> på mit arbejde.
> Med venlig hilsen
> Lars

---

Anton Vestergaard wrote:
>
> Hvordan?

Grundlæggende ved at lave kald til API'en CreateThread. Du kan læse om
det på blandt andet: <http://www.freevbcode.com/ShowCode.Asp?ID=1287>

Med venlig hilsen
Lars Hoffmann

---

Hej "Anton Vestergaard" <anton_dkNONO@hotmail.com>

>Men jeg forstår ikke helt at C skulle være så meget hurtigere end VB.
>I bund og grund sker der jo det samme i bege sprog. Det er de samme
>API'er der bruges.

Men der er andet end API kald i et program. Med C overlader man mindre
til fortolkeren, dvs. der er bedre betingelser for effektiv kode.

>Jeg tænker på vores små applikationer til at opdatere en db osv.

Til smånips er det nok ligegyldigt, ja.

>Jeg kan godt se at hvis man skal lave noget grafik (spil), kan man nok
>opnå en del med C (C++). Men mon så ikke man burde tage skridtet
>fuldt ud (Asm).

Fordi det er meget meget tidskrævende at skrive assembler. Det er
bedre at kode i C og optimere kritiske rutiner i asm, det er så vidt
jeg ved også hvad de gør i (nogle) spil.

--
Lars Kim Lund
http://www.net-faq.dk/

---

"Lars Kim Lund" <larskim@mail.com> skrev i en meddelelse
news:43t4jt0bilr0en79uq6u8718lgj9jvabs3@news.tele.dk...
> Hej "Anton Vestergaard" <anton_dkNONO@hotmail.com>
>
> >Men jeg forstår ikke helt at C skulle være så meget hurtigere end VB.
> >I bund og grund sker der jo det samme i bege sprog. Det er de samme
> >API'er der bruges.
>
> Men der er andet end API kald i et program. Med C overlader man mindre
> til fortolkeren, dvs. der er bedre betingelser for effektiv kode.

Det har også været min opfattelse. Men i praksis kan jeg ikke se den store
forskel.
Jeg har ladet mig fortælle at compileren i VB6 bygger på en C compiler
(v4.2), og
dermed oversætter VB til C inden compilering.
Igen, jeg kan ikke undebygge min påstand.

>
> >Jeg tænker på vores små applikationer til at opdatere en db osv.
>
> Til smånips er det nok ligegyldigt, ja.
>
> >Jeg kan godt se at hvis man skal lave noget grafik (spil), kan man nok
> >opnå en del med C (C++). Men mon så ikke man burde tage skridtet
> >fuldt ud (Asm).
>
> Fordi det er meget meget tidskrævende at skrive assembler. Det er
> bedre at kode i C og optimere kritiske rutiner i asm, det er så vidt
> jeg ved også hvad de gør i (nogle) spil.

Det kan vi hurtigt blive enige om. Det var egentlig også det du skriver jeg
mente.

/Anton

>
> --
> Lars Kim Lund
> http://www.net-faq.dk/

---

Hvis du i Microsoft Jet opretter et index,
er den stinkende hurtig til at finde en post.
Langt hurtigere end end en "select * from
blabla where FilNavn = " & MyFile$
Performance for et bibliotek med 40.000 filer
vil være mere afhængigt af filsystemet som helhed
og mindre forudsigeligt.

Jeg tror ikke du opnår andet end mere uoverskuelig kode,
ved at opdele tabellen i undertabeller.

mhv

Per



"Mads Chr. Olesen" <MadsChrO@Yahoo.com> wrote in message
news:9gqfbv$bbb$1@news.inet.tele.dk...
> Da jeg står og skal finde en post i en database fra mit program, vil jeg
> gerne høre om der er nogen der ved hvad der er hurtigst:
> 1. At åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller
> 2. At søge i en database (med samme antal poster) efter alle poster hvor
id
> = 172
> 3. Opdele databasen i undertabeller, hvor tabel 1 indeholder 1-1000, tabel
> 2: 1001-2000 osv. Hvad er da det optimale antal poster pr. tabel?
>
> Håber der er nogen der har erfaring med det.
>
> ---
> Mads Chr. Olesen
> MadsChrO@Yahoo.com
>
>

---

Mads Chr. Olesen skrev:
> Da jeg står og skal finde en post i en database fra mit program, vil jeg
> gerne høre om der er nogen der ved hvad der er hurtigst:
> 1. At åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller

Mig bekendt foregår søgninger efter filnavne i et bibliotek rent
sekventielt.
Det har den konsekvens, at jo flere filer man har i et bibliotek, des
(gennemsnitlig) længere tid tager det at åbne en fil.
Hvis filen ikke findes går det helt galt, idet der så skal sammenligne med
40.000 filnavne, før filsystemet beslutter at filen ikke findes i
biblioteket.

> 2. At søge i en database (med samme antal poster) efter alle poster hvor
id
> = 172

Hvis du har et indeks på feltet, koster det ikke mange disk-operationer at
finde posten.

> 3. Opdele databasen i undertabeller, hvor tabel 1 indeholder 1-1000, tabel
> 2: 1001-2000 osv.

Hvis du bruger indekser får du ikke noget ud af at opdele i mindre tabeller.
Hvis du IKKE bruger indekser, vil du naturligvis få samme fordel, som hvis
du delte op i flere underbiblioteker.

> Hvad er da det optimale antal poster pr. tabel?

0 (nul). Så vil enhver søgning gå hurtigst.
Hvis der er 1 post tager det samme eller lidt længere tid.
2 poster samme eller lidt længere tid end med 1 post.

Altså set sådan rent gennemsnitligt. Man kan sagtens komme ud for at en
tabel med 1000 poster er hurtigere at søge i end en med 900 poster (hvis der
bruges indeks). Det afhænger helt af hvor god databasen er til at gøre sit
indeks så optimalt som muligt (formindske søgetræet).

Helt generelt vil du med store datamænger (40.000 poster er ikke ret mange)
få en betydelig bedre performance hvis du bruger en "rigtig" database-server
(f.eks. MS SQL Server eller Oracle) end hvis du bruger en fil eller en lokal
fil-baseret database som Access.

Spørgsmålet er - hvis det skal gå RIGTIGT hurtigt - hvor store datamængder
der skal behandles?
Det drejer sig måske nok om 40.000 styk, med hvad består data af, og hvad
skal der gøres med dem?

Husk på at det jo naturligvis går meget hurtigere end alt det andet, hvis du
kan have dine data i RAM hele tiden. F.eks. en stor tabel. Men det afhænger
jo af HVORDAN du behandler dine data, om det er en gangbar løsning.

-------
Tomas

---

After drinking 3 Pan Galactic Gargle Blasters, "Tomas Christiansen"
<toc@blikroer.dk.removethis> mumbled in
news:zblY6.66$C_6.10002@news.get2net.dk:
> Mads Chr. Olesen skrev:
>> Da jeg står og skal finde en post i en database fra mit program, vil
>> jeg gerne høre om der er nogen der ved hvad der er hurtigst: 1. At
>> åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller

Det hele afhænger meget af hvad det er du skal søge efter! Kan du
ikke give et eksempel på hvad der ligger i filen, hvad man vil søge
efter i filen og hvordan filerne og filnavne er organiseret.

> Mig bekendt foregår søgninger efter filnavne i et bibliotek rent
> sekventielt.
> Det har den konsekvens, at jo flere filer man har i et bibliotek,
> des (gennemsnitlig) længere tid tager det at åbne en fil.
> Hvis filen ikke findes går det helt galt, idet der så skal
> sammenligne med 40.000 filnavne, før filsystemet beslutter at filen
> ikke findes i biblioteket.

Man kunne lave et træstruktur af kataloger og gemme et mindre antal
filer i hvert katalog. Så er det bare at finde ud af hvordan man
finder filerne igen, men det afhænger af ovenstående spørgsmål om
denne løsning overhovedet er smart!


Andrew
--
*** The opinions expressed are not necessarily those of my employer. ***
* Software Engineer * Leif Andrew Rump * BLIK og ROERarbejderforbundet *
* Immerkaer 42, 2650 Hvidovre * Tlf: +45 3638 3638, Fax: +45 3638 3639 *
Home: N55°39'50.9" E12°27'47.4" (WGS 84) Work: N55°41'14.3" E12°32'37.5"
E-mail: mailto:newandrew@rump.dk WWW http://www.rump.dk/homepage/andrew/

---

Det jeg skal søge efter er en streng, og når jeg har fundet posten skal jeg
gemme de data posten indeholder i nogle variabler.
Efter at have læst hvad de forskellige har skrevet er jeg rimelig sikker på
at jeg vil bruge en database med index på det felt jeg skal søge i.
Mit næste spørgsmål er så (ud af ren nysgerrighed) hvordan et index virker?

"Leif Andrew Rump" <newandrew@rump.dk> skrev i en meddelelse
news:Xns90C78EC9FAA9Dnewandrewrumpdk@130.227.3.84...
> After drinking 3 Pan Galactic Gargle Blasters, "Tomas Christiansen"
> <toc@blikroer.dk.removethis> mumbled in
> news:zblY6.66$C_6.10002@news.get2net.dk:
> > Mads Chr. Olesen skrev:
> >> Da jeg står og skal finde en post i en database fra mit program, vil
> >> jeg gerne høre om der er nogen der ved hvad der er hurtigst: 1. At
> >> åbne en fil, f.x. "172.txt", i et bibliotek med 40.000 filer eller
>
> Det hele afhænger meget af hvad det er du skal søge efter! Kan du
> ikke give et eksempel på hvad der ligger i filen, hvad man vil søge
> efter i filen og hvordan filerne og filnavne er organiseret.
>
> > Mig bekendt foregår søgninger efter filnavne i et bibliotek rent
> > sekventielt.
> > Det har den konsekvens, at jo flere filer man har i et bibliotek,
> > des (gennemsnitlig) længere tid tager det at åbne en fil.
> > Hvis filen ikke findes går det helt galt, idet der så skal
> > sammenligne med 40.000 filnavne, før filsystemet beslutter at filen
> > ikke findes i biblioteket.
>
> Man kunne lave et træstruktur af kataloger og gemme et mindre antal
> filer i hvert katalog. Så er det bare at finde ud af hvordan man
> finder filerne igen, men det afhænger af ovenstående spørgsmål om
> denne løsning overhovedet er smart!
>
>
> Andrew
> --
> *** The opinions expressed are not necessarily those of my employer. ***
> * Software Engineer * Leif Andrew Rump * BLIK og ROERarbejderforbundet *
> * Immerkaer 42, 2650 Hvidovre * Tlf: +45 3638 3638, Fax: +45 3638 3639 *
> Home: N55°39'50.9" E12°27'47.4" (WGS 84) Work: N55°41'14.3" E12°32'37.5"
> E-mail: mailto:newandrew@rump.dk WWW http://www.rump.dk/homepage/andrew/

---

Mads Chr. Olesen skrev:
> Det jeg skal søge efter er en streng, og når jeg har fundet posten skal
jeg
> gemme de data posten indeholder i nogle variabler.

Det LYDER som en typisk database-opgave.

> Efter at have læst hvad de forskellige har skrevet er jeg rimelig sikker
på
> at jeg vil bruge en database med index på det felt jeg skal søge i.
> Mit næste spørgsmål er så (ud af ren nysgerrighed) hvordan et index
virker?

Det virker godt

Hvis det felt, som du ønsker at søge på også er nøglen til din post (det er
det mest almindelige), får du formentlig automatisk lagt et indeks på feltet
(alt afhænger jo af hvilken database, som du vil bruge). I visse tilfælde
kan de være fordelagtigt at lægge et indeks på felter som ikke er
nøgle-felter (hvis der ofte foretages søgninger på disse felter).

Et indeks er såmænd blot en "organiseret indholdsfortegnelse", der som sådan
ikke er synlig for brugeren, men som databasen bruger, når der søges på det
pågældende felt.

Tag som eksempel, at du har en tabel ved navn Tab med 40.000 poster, som har
2 felter: Nøg og Dat.

Du foretager nu en søgning: select Dat from Tab where Nøg=123

Hvis der er et indeks på feltet Nøg, kan databasen slå "direkte" op på
værdien 123 (så "direkte" som det nu kan lade sig gøre gennem én eller anden
form for søgetræ).

Hvis der IKKE er et indeks på feltet Nøg, er databasen nødt til at søge
gennem alle posterne én for én for at finde den, med værdien 123. Den kan
være heldig at det er den første post (1 læsning), eller uheldig at det er
den sidste post (40.000 læsninger).

Dermed vil læsninger i 99,9% (CIRKA) af tilfældene gå hurtigere med indeks,
men indsættelse af nye poster vil gå lidt langsommere med indeks.

-------
Tomas

---

Hej "Tomas Christiansen" <toc@blikroer.dk.removethis>

>Mig bekendt foregår søgninger efter filnavne i et bibliotek rent
>sekventielt.

Men da ikke hvis man ved hvad filen hedder. Det er bestemt min
erfaring at systemet finder filen ret direkte, hvis man angiver en
absolut path.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund skrev:
> >Mig bekendt foregår søgninger efter filnavne i et bibliotek rent
> >sekventielt.

> Men da ikke hvis man ved hvad filen hedder. Det er bestemt min
> erfaring at systemet finder filen ret direkte, hvis man angiver en
> absolut path.

Hmmm. Jeg har forsøgt mig lidt frem under Windows 2000, og det ser for det
første ud til at der er en begrænsning på biblioteksstørrelsen på ca. 1
Mbyte. Dermed har antallet af bogstaver i filnavnene i et givent bibliotek
betydning for hvor mange filer, som der kan være i det pågældende bibliotek!

Dernæst ser det ud til at Windows 2000 er ret god til at cache
informationerne i et bibliotek.
Det kan tage TEMMELIG lang tid at indlæse informationerne i Explorer
(faktisk op til flere minutter), men når det først er der og er sorteret,
går det hurtigt.

Åbner man en vilkårlig fil, i et bibliotek med mange filer, har
biblioteks-STØRRELSEN en kraftig indflydelse på hvor lang tid det tager for
filsystemet at finde filen. Oftest taler vi om en søgetid på 10-40 ms, men
det er lykkedes mig at komme helt op på ca. 240 ms - det er ret lang tid.

Det ser ud til at HELE biblioteket ikke bliver cachet, selvom man læser den
første, midterste og sidste fil. Det tyder snarere på at "blokke" af filer
bliver cachet, så hele biblioteket lidt efter lidt ender med at været
cachet. Men hvad betyder vel også 1 Mbyte idag?

Mine tests tyder på én eller anden organiseret form for opbygning, som
muliggør søgning efter en fil, uden at skulle gennemsøge HELE biblioteket.

Dermed må jeg give dig ret, Lars, mht. at det generelt er ret hurtigt at
finde en fil (der kan dog være tilfælde hvor det kan tage noget tid, men det
er kun de første par gange).

-------
Tomas

---

Hej "Tomas Christiansen" <toc@blikroer.removethis.dk>

>Hmmm. Jeg har forsøgt mig lidt frem under Windows 2000, og det ser for det
>første ud til at der er en begrænsning på biblioteksstørrelsen på ca. 1
>Mbyte. Dermed har antallet af bogstaver i filnavnene i et givent bibliotek
>betydning for hvor mange filer, som der kan være i det pågældende bibliotek!

Det har jeg aldrig hørt, hvordan tester du det - og kan du finde
dokumentation for det?

>Dernæst ser det ud til at Windows 2000 er ret god til at cache
>informationerne i et bibliotek.
>Det kan tage TEMMELIG lang tid at indlæse informationerne i Explorer
>(faktisk op til flere minutter), men når det først er der og er sorteret,
>går det hurtigt.

Nu er explorer noterisk langsom fordi den læser alle filers headers,
ikoner, properties og what-not. Explorer er blevet signifikant
langsommere, tror også det har noget at gøre med hvilken protokol man
bruger (microsoft-ds eller classic netbios windows networking) - altså
hvis vi taler netværk. Det er tydeligt når man sidder bag en 128Mbps
linie.

>Åbner man en vilkårlig fil, i et bibliotek med mange filer, har
>biblioteks-STØRRELSEN en kraftig indflydelse på hvor lang tid det tager for
>filsystemet at finde filen. Oftest taler vi om en søgetid på 10-40 ms, men
>det er lykkedes mig at komme helt op på ca. 240 ms - det er ret lang tid.

Hvordan måler du det?

I hvert fald bør vi kunne blive enige om at klienten ikke begynder at
læse hele directoriet for at finde en fil. Jeg har testet det på en
langsom linie.

dir winnt mappe på en remote maskine (2000+ filer), tager en del
sekunder i en kommandoprompt.

dir filnavn.exe kommer hurtigt.

type filnavn.txt (lille test-fil) kommer prompte.

Ergo laver klienten en forespørgsel (jeg vil gerne have fil xx) og
remote maskinen returnerer svaret.

Der er tale om caching, men det er vigtigt at bemærke at det foregår
på den maskine man læser fra.

Lad os for argumentets skyld sige at du har 10.000 filer af 10 MB. Lad
os sige du har de 10.000 filer liggende i et directory kontra en SQL
(fx.) database.

Jeg tror ikke du skal være alt for sikker på at det er hurtigere at
hente filen i en SQL db end fra filsystemet. Måske lidt, men ikke
signifikant, hvis det blot er et spørgsmål om at hente en fil og man
kender den absolutte path.

>Mine tests tyder på én eller anden organiseret form for opbygning, som
>muliggør søgning efter en fil, uden at skulle gennemsøge HELE biblioteket.

Foregår det lokalt kører der jo også file cache. Jo mere RAM, des mere
bliver brugt til file caching. Det er også parametre der kan tweakes,
hvis man ønsker det, check sysinternals.com

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund hamrede i tastaturet:
> >... der er en begrænsning på biblioteksstørrelsen på ca. 1 Mbyte.

> Det har jeg aldrig hørt, hvordan tester du det - og kan du finde
> dokumentation for det?

Jeg kom først bagefter i tanke om at den PC, som jeg afprøvede det på, var
preinstalleret med FAT32. Det kan (læs: vil) jo se anderledes ud med NTFS
(som jeg ellers normalt til
hver en tid vil bruge).


> >filsystemet at finde filen. Oftest taler vi om en søgetid på 10-40 ms,
> >men det er lykkedes mig at komme helt op på ca. 240 ms - det er
> >ret lang tid.

> Hvordan måler du det?

Nu er det er jo en VB gruppe detteher
Så jeg lavede et lille program, som kan åbne en vilkårlig af filerne i mine
testbiblioteker. Det er ret let at måle den tid, det tager at åbne en fil.


> I hvert fald bør vi kunne blive enige om at klienten ikke begynder at
> læse hele directoriet for at finde en fil. Jeg har testet det på en
> langsom linie.

Ja.


> Jeg tror ikke du skal være alt for sikker på at det er hurtigere at
> hente filen i en SQL db end fra filsystemet. Måske lidt, men ikke
> signifikant, hvis det blot er et spørgsmål om at hente en fil og man
> kender den absolutte path.

Med FAT32, er man begrænset til så få filer, at en database sikkert ikke er
hurtigere (så længe vi taler om et direkte opslag og ikke komplicerede
søgninger).

Jeg stoppede mine test, da jeg havde oprettet knap 64.000 filer med korte
filnavne (ca. 9 tegn),
men blev stoppet af begrænsningen på biblioteksstørrelsen ved 6553 filer med
lange filnavne (ca. 112 tegn).

-------
Tomas