2009-02-18 57 views
1

我相信很多人已經注意到,當你有一個大的應用程序(即需要幾MB的DLL)需要比第一次加載更快。 如果您在應用程序中讀取大文件,則會發生同樣的情況。在第一次之後它讀得更快。大的應用程序/文件加載時間

這是什麼影響?我想這是硬盤緩存,或者操作系統增加了一些自己的內存緩存。

您使用什麼技術來加速大型應用程序和文件的加載時間?

在此先感謝

注意:這個問題指的是Windows

補充:哪些因素會影響操作系統的緩存大小?在某些應用程序中,一分鐘左右後文件再次緩慢加載,因此緩存會填滿一分鐘?

回答

6

Windows的內存管理器實際上很漂亮 - 它提供內存請求並充當磁盤緩存。如果系統上有足夠的可用內存,那麼最近訪問的大量文件將駐留在內存中。在需要物理內存之前,這些DLL將保留在緩存中 - 全部都是CacheManager。

至於如何幫助,請查看延遲加載您的DLL。 LoadLibrary的優點只有在你需要它的時候纔會自動完成,所以你的代碼中沒有LoadLibrary/GetProcAddress。(好吧全自動,儘可能只需要添加一個鏈接器命令開關):

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

或者,你可以預加載,如Office和其他人(如上所述),但我個人討厭 - 最初啓動時放慢計算機速度。

1

是的,任何從硬盤讀入的內容都會被緩存,所以第二次加載的速度會更快。基本假設是,僅從HD使用一大塊數據很少,然後丟棄它(這在實踐中通常是一個很好的假設)。通常情況下,我認爲它是實現緩存的操作系統(內核),佔用了大量內存,但我不確定現代硬盤是否具有內置緩存功能。 (我曾經寫過一個小內核作爲學術項目;內存中的高清數據緩存是它的特色之一)

9

有兩件事會影響到這一點。首先是硬盤緩存(由磁盤完成,影響不大,操作系統往往影響更大)。第二個是Windows(和其他操作系統)沒有理由在卸載完DLL後卸載DLL,除非內存是其他需要的。這是因爲DLL可以很容易地在進程之間共享。

因此,即使在使用應用程序的應用程序消失後,DLL仍有掛起的習慣。如果另一個應用程序決定需要DLL,則它已經在內存中,只需將其映射到進程地址空間。

我已經看到一些應用程序預加載它們所需的DLL(通常稱爲QuickStart,我認爲MS Office和Adobe Reader都這樣做),以便感知加載時間更好。

1

影響程序啓動時間的另一個因素是Superfetch,這是一種在Windows XP中引入的技術。從本質上講,它監控程序啓動時的磁盤訪問,識別文件訪問模式,並試圖「聚合」所需數據以便更快地訪問(例如,通過按照其加載順序在磁盤上順序重新排列數據)。

正如其他人提到的,一般而言,任何讀取操作都可能被Windows磁盤緩存緩存,並被重用,除非內存是其他操作所需的。

+0

XP的重新排列文件稱爲預取。 Vista在開始之前將東西加載到內存中稱爲SuperFetch。 – 2009-02-20 16:55:24

4

我看到兩種可能性:在系統啓動時

  • 預緊yourlibraries作爲已經mentionned辦公室,OpenOffice和其他人這樣做。

我不是那種解決方案的忠實粉絲:它會讓你的啓動時間更長,並且消耗大量內存。

  • 僅在需要時動態加載您的DLL(請參閱LoadLibrary)。不幸的是,所有DLL都不可能。

例如,爲什麼在啓動時加載DLL以XYZ格式導出文件,如果您不確定是否需要?當用戶選擇這種導出格式時加載它。

我有一個夢想,Adobe Acrobat使用這種方法,而不是每次我想顯示PDF文件時都不會使用插件負載!

根據您的需求,你可能需要使用這兩種技術:預裝需求只有特定的插件一些大heavliy使用librairies和負載...

0

系統緩存用於任何脫離盤。這包括文件元數據,所以如果您使用的應用程序可以打開大量文件(例如目錄掃描程序),那麼如果您的應用程序運行時會佔用大量內存,則可以輕鬆刷新緩存。

對於我使用的東西,我更喜歡使用少量的大文件(> 64 MB到1 GB)和異步非緩衝I/O。而且每隔一段時間都會有一個好的碎片整理。

2

可能值得一看的一個項目是「rebasing」。每個DLL都有一個預設的「基址」地址,它更喜歡將其加載到內存中。如果應用程序正在將DLL加載到不同的地址(因爲首選的DLL不可用),則DLL將加載到新地址並「重新綁定」。粗略地說,這意味着dll的一部分會即時更新。這隻適用於本機映像,而不適用於.NET虛擬機.dll。

這真的老了MSDN文章涵蓋rebase'ng: http://msdn.microsoft.com/en-us/library/ms810432.aspx

不知道是否很大一部分仍然適用(這是一個很老的文章)......但在這裏是一個誘人的報價:

首選一個較大的DLL通過幾個 小的;確保操作系統不需要 搜索DLL很長;和 如果有機會 操作系統操作系統(或者, 嘗試選擇您的基地址 不可能重新綁定),請避免許多修正。

順便說一句,如果你在處理.NET,那麼「ngen'ng」你的應用程序/ DLL應該有助於加快速度(ngen = natve圖像生成)。

相關問題