windows - Stort program/fil load-time

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg er sikker på, at mange har bemærket, at når du har en stor applikation (dvs. noget der kræver et par MB'er af DLL'er) laster det meget hurtigere anden gang end første gang.
Det samme sker, hvis du læser en stor fil i din ansøgning. Det læses meget hurtigere efter første gang.


Hvad påvirker dette? Jeg antager, at dette er harddiskens cache, eller er operativsystemet tilføjet noget hukommelsescaching selv.


Hvilke teknikker bruger du til at fremskynde indlæsningstiderne for store applikationer og filer?


Tak på forhånd


Bemærk : spørgsmålet refererer til Windows


Tilføjet: Hvad påvirker cachestørrelsen på operativsystemet? I nogle apps genoptages filerne langsomt igen efter et minut eller så, så cachen fylder et minut?

Bedste reference


Windows hukommelsesadministrator er faktisk ret fladt - det hukommelseskrav, der ønskes, og fungerer som diskcache. Med tilstrækkelig ledig hukommelse på systemet, vil mange filer, der er blevet brugt for nylig, forblive i hukommelsen. Indtil den fysiske hukommelse er nødvendig, disse DLL'er forbliver i cache - alt sammen CacheManager.


For så vidt som hvordan du hjælper, se på forsinkelse Indlæser dine DLL'er. Fordelene ved LoadLibrary kun når du har brug for det, men automatisk, så du ikke har LoadLibrary/GetProcAddress på hele din kode. (Velautomatisk, så længe du bare behøver at tilføje en linker kommandostop):


http://msdn.microsoft.com/en-us/library/yx9zd12s.aspx[1]


Eller du kan pre-load som Office og andre gør (som nævnt ovenfor), men jeg hader det personligt - sænker computeren ved første opstart.

Andre referencer 1


To ting kan påvirke dette. Den første er harddisk caching (lavet af disken, som har ringe indflydelse og af OS, som har tendens til at have større indflydelse). Det andet er, at Windows (og andet OS ') har ringe grund til at aflæse DLL'er, når de er færdige med dem, medmindre hukommelsen er nødvendig for noget andet. Dette skyldes, at DLL'er nemt kan deles mellem processer.


Så DLL'er har en vane at hænge rundt, selv efter at de applikationer, der brugte dem, forsvinder. Hvis en anden applikation beslutter, at DLL'en er nødvendig, er den allerede i hukommelsen og skal bare kortlægges i processerne adresserum.


Jeg har set nogle programmer forudindlæse deres nødvendige DLL'er (normalt kaldet QuickStart, jeg tror både MS Office og Adobe Reader gør dette), så de opfattede belastningstider er bedre.

Andre referencer 2


Jeg ser to muligheder:



  • forudindlæser dine biblioteker ved systemstart som allerede nævnt Office, OpenOffice og andre gør netop det.



Jeg er ikke en stor fan af den løsning: Det gør din boot tid længere og spiser meget hukommelse.



  • Upload din DLL dynamisk (se LoadLibrary), når det er nødvendigt. Desværre ikke muligt med alle DLL'er.



For eksempel, hvorfor skal du ved starten starte en DLL for at eksportere filen i XYZ-format, når du ikke er sikker på, at det nogensinde vil være nødvendigt ?? Indlæs det, når brugeren valgte dette eksportformat.


Jeg har en drøm, hvor Adobe Acrobat bruger denne tilgang, i stedet for at overdrive mig med masser af plugins, som jeg aldrig bruger hver gang jeg vil vise en PDF-fil!


Afhængigt af dine behov kan du muligvis bruge begge teknikker: forudindlæse nogle store heavliy brugte librairies og indlæse kun specifikke plugins på forespørgsel ...

Andre referencer 3


Et emne, der måske er værd at se på, er 'genopretning'. Hver DLL har en forudindstillet 'base' adresse, som den foretrækker at blive indlæst i hukommelsen på. Hvis en applikation læser DLL'en på en anden adresse (fordi den foretrukne ikke er tilgængelig), lægges DLL'en i den nye adresse og 'genkøbs'. Omfattende betyder det, at dele af dll'en opdateres i flyve. Dette gælder kun for native billeder i modsætning til .NET vm .dll 's.


Denne rigtig gamle MSDN-artikel dækker rebase 'ng:
http://msdn.microsoft.com/en-us/library/ms810432.aspx[2]


Ikke sikker på, om meget af det stadig gælder (det er en meget gammel artikel) ... men her er et tiltrækkende citat:



  Foretrækker en stor DLL over flere
  små; sørg for at
  operativsystemet behøver ikke at
  Søg efter DLL'erne meget lang; og
  undgå mange reparationer, hvis der er en chance
  at DLL'en kan blive genopbygget af
  operativsystem (eller alternativt
  Prøv at vælge dine baseadresser sådan
  at genopretning er usandsynlig).



Btw hvis du 'beskæftiger sig med .NET derefter' ngen 'ng' skal din app/dlls hjælpe med at fremskynde tingene (ngen=natve image generation).

Andre referencer 4


Ja, alt, hvad der læses fra harddisken, er cachelagret, så det bliver hurtigere for anden gang. Den grundlæggende antagelse er, at det er sjældent at bruge en stor klump af data fra HD kun én gang og derefter kassere den (dette er normalt en god antagelse i praksis). Typisk tror jeg, at det er operativsystemet (kernen), der implementerer cachen og tager en del RAM til det, selvom jeg ikke er sikker på, om moderne harddiske har nogle indbyggede cache-muligheder. (Jeg skrev en gang en lille kerne som et akademisk projekt; caching af HD-data i hukommelsen var en af ​​de dets funktioner)

Andre referencer 5


En ekstra faktor, der påvirker programstarttidspunktet er Superfetch, en teknologi, der introduceres med (tror jeg) Windows XP. I det væsentlige overvåger den diskadgang under programstart, genkender filadgangsmønstre, og de forsøger at 'samle' de krævede data for hurtigere adgang (for eksempel ved at omarrangere dataene i rækkefølge på disk ifølge dets indlæsningsrækkefølge).


Som de andre nævnte, vil enhver læsning sandsynligvis blive cachelagret af Windows-diskcachen og genbruges, medmindre hukommelsen er nødvendig til andre operationer.

Andre referencer 6


NGENing af samlingerne kan hjælpe med starttiden, men runtime kan ske (Sommetider er NGened-koden ikke så optimal som OnDemand Compiled-kode)


NGENing kan også gøres i baggrunden: http://blogs.msdn.com/davidnotario/archive/2005/04/27/412838.aspx
[3]


Her er en anden god artikel NGen og Performance http://msdn.microsoft.com/en-us/magazine/cc163808.aspx[4]

Andre referencer 7


Systembufferen bruges til alt, der kommer ud af disken. Det omfatter filmetadata, så hvis du bruger applikationer, der åbner et stort antal filer (f.eks. Katalogscannere), kan du nemt spyle cachen, hvis du også har programmer, der spiser meget, der spiser meget.


For de ting, jeg bruger, foretrækker jeg at bruge et lille antal store filer (> 64 MB til 1 GB) og asynkron ikke-buffereret I/O. Og en god ol 'defragter hver gang imellem.