View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001668Far Manager_Commonpublic2011-01-17 06:152011-03-24 08:19
Reporteralexeypa Assigned ToDrKnS  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformx64OSWindowsOS Version7
Product Version2.0 
Fixed in Version3.0 
Summary0001668: Классы CachedRead и CacheWrite крайне неэффективны с точки зрения производительности.
DescriptionМетод CachedRead::Read генерирует огромное количество вызовов SetFilePointer. Это приводит к тому, что при непрерывном скроллировании в просмотрщике CPU взлетает до небес и скроллинг заметно притормаживает.

В проложенном файле (CachedRead_Read_88percent.png) видно, что вызовы SetFilePointer съедают 88% всего времени, затраченного на счтение данных из просматриваемого файла. Собственно затраты времени на собственно чтение данных настолько малы, что практически не замечаются профайлером.

Вполне очевидно, что все вызовы SetFilePointer нужны для синхронизации позиции в файле между File и CachedRead. Также очевидно, что это никуда не годится.

CachedWrite написан по аналогичной схеме. По всей видимости обладает теми же проблемами.

PS. А чем обыкновенный FILE* не подошел?
Steps To Reproduce1. Запустите Far под любимым профайлером.
2. Откройте большой файл в просмотрщике.
3. Нажмите PageDown и не отпускайте пару минут. Файл должен быть достаточно большим, чтобы за это время не дойти то конца файла.
3.1. Следите на CPU в task manager.
4. Загрузите трейс в профайлер и посмотрите на то, куда уходит время.
TagsNo tags attached.
Build1904

Activities

alexeypa

2011-01-17 06:15

reporter  

CachedRead_Read_88percent.png (79,788 bytes)   
CachedRead_Read_88percent.png (79,788 bytes)   

DrKnS

2011-01-17 10:38

administrator   bugnote:0006137

Да, есть такое. Надо реализовать в этих классах некий "виртуальный" поинтер, или внедрить всё это в File.


> PS. А чем обыкновенный FILE* не подошел?

В двух словах: поддержка elevation.
Уносить в отдельный процесс и всё семейство HANDLE-функций, и всё семейство FILE*-функций - перебор.

alexeypa

2011-01-17 15:52

reporter   bugnote:0006145

Last edited: 2011-01-17 15:56

 > В двух словах: поддержка elevation.
> Уносить в отдельный процесс и всё семейство HANDLE-функций, и всё семейство FILE*-функций - перебор.

Этого совсем не нужно делать. Более того, набор оберток для elevation тоже не нужен. По C_FUNCTION_CREATEFILE, привилегированный процесс должен вернуть не свой HANDLE, а сделать DuplicateHandle в непривилигерованный процесс и вернуть копию HANDLE. После чего непривигированный процесс может спокойно делать с этим HANDLE все то, что он делает с локально открытым HANDLE.

А текущий дизайн не очень хорош. Во-первых данные копируются через pipe. Во-вторых это дырка в безопаности, так как пепривилигерованный процесс может заставить привилигерованный читать любой открытый им файл, передав значение другого хендла. Откыть отдельный баг по этому поволу?

Далее, HANDLE прекрасно заворачивается в FILE* с помощью _fdopen.

alexeypa

2011-01-17 15:55

reporter   bugnote:0006146

Да, еще. для собственной реализации кеша в данном случае лучше подоходит использование memory mapped files.

DrKnS

2011-01-17 17:50

administrator   bugnote:0006147

> После чего непривигированный процесс может спокойно делать с этим HANDLE все то, что он делает с локально открытым HANDLE.

Интересно, попробуем и так.

> Откыть отдельный баг по этому поволу?

Конечно.

DrKnS

2011-03-09 10:12

administrator   bugnote:0006505

1904.

Issue History

Date Modified Username Field Change
2011-01-17 06:15 alexeypa New Issue
2011-01-17 06:15 alexeypa File Added: CachedRead_Read_88percent.png
2011-01-17 10:38 DrKnS Note Added: 0006137
2011-01-17 15:52 alexeypa Note Added: 0006145
2011-01-17 15:52 alexeypa Note Edited: 0006145
2011-01-17 15:52 alexeypa Note Edited: 0006145
2011-01-17 15:55 alexeypa Note Added: 0006146
2011-01-17 15:55 alexeypa Note Edited: 0006145
2011-01-17 15:56 alexeypa Note Edited: 0006145
2011-01-17 17:50 DrKnS Note Added: 0006147
2011-01-17 21:22 DrKnS Assigned To => DrKnS
2011-01-17 21:22 DrKnS Status new => assigned
2011-03-09 10:12 DrKnS Note Added: 0006505
2011-03-09 10:12 DrKnS Status assigned => feedback
2011-03-24 08:19 DrKnS Build => 1904
2011-03-24 08:19 DrKnS Status feedback => closed
2011-03-24 08:19 DrKnS Resolution open => fixed
2011-03-24 08:19 DrKnS Fixed in Version => 3.0