Сколько строк должно быть в (основном) буфере виртуального элемента управления Listview?

Question

Сколько строк должно быть в (основном) буфере виртуального элемента управления Listview?

Я наблюдаю за приложением в чистом 'c' к Win32 API. Существует ODBC-соединение с базой данных, которая будет извлекать элементы (фактически строки).

Пример кода MSDN предполагает наличие фиксированного размера буфера 30 для конечного кэша (который почти наверняка не будет оптимальным). Я думаю, что конечный кэш и основной кэш должны быть одинакового размера.

Я думаю, что размер буфера должен превышать максимальное количество элементов, которые могут отображаться в виде списка за один раз. Я думаю, это можно пересчитать каждый раз при изменении размера Listivew?

Или лучше просто использовать большое фиксированное значение. Если да, что это за значение?

Answer 1

Уведомление LVN_ODCACHEHINT позволит вам узнать, сколько предметов он собирается запросить. Это может помочь вам решить, насколько большим должен быть ваш кеш.

Answer 2

Используйте ListView_ApproximateViewRect (или сообщение LVM_APPROXIMATEVIEWRECT), чтобы получить высоту прямоугольника представления.

Используйте ListView_GetItemRect (или сообщение LVM_GETITEMRECT), чтобы получить высоту элемента.

Разделите высоту прямоугольника вида на высоту элемента, чтобы получить количество элементов, которое может поместиться в вашем виде. Выполните этот расчет для каждого события размера.

Затем создайте свой буфер соответственно.

Answer 3

Казалось бы, ответ: (Или случайная коллекция заметок, когда я возился с идеями)

Как общий ответ для буферов: Начните с некоторой суммы, в этом случае экран заполнен (я добавляю дополнительную строку в случае, если следующая часть частично раскрыта), а затем каждый раз, когда экран прокручивается, удваивает размер буфера (до того момента, пока у вас не закончится память ).

Что может показаться неправильным. Как оказалось, большинство способов загрузки данных все готово в буфере. ODBC вызывает File I / O. Почти все, о чем я не могу думать, либо находится в памяти, либо пересчитывается на лету. Это означает, что ответ на самом деле таков: возьмите значения, указанные в LVN_ODCACHEHINT (и добавьте 1 с каждой стороны - кажется, это работает быстрее, если у вас нет интегральной высоты).

Answer 4

@ Brian R. Bondy Спасибо за подробную помощь по получению количества предметов. На самом деле я был полностью готов к тому, чтобы понять, что это можно сделать (для представления списка или отчета) с ListView_GetCountPerPage, и я бы использовал ваш способ получить его для других, хотя мне не нужен ListView_ApproximateViewRect, так как все будет готово знать новый размер ListView.

@ Lars Truijens Я уже использую LVN_ODCACHEHINT и хотя уже собирался использовать это для установки размера буфера, однако мне нужно прочитать данные SQL до конца, чтобы найти последний элемент, чтобы получить количество строк, возвращаемых из ODBC , Поскольку это было бы наилучшее время для заполнения «конечного кэша», я думаю, что мне нужно установить количество элементов (и, следовательно, заполнить буфер), прежде чем мы получим вызов LVN_ODCACHEHIN.

Полагаю, мой настоящий вопрос - это вопрос оптимизации, на который, по-моему, Брайан намекнул на ответ. Объем накладных расходов на очистку буфера и перераспределение памяти меньше, чем накладные расходы на выход в сеть и чтение ODBC, некоторые делают буфер довольно маленьким и часто меняют его.

Это правильно?

Я немного поигрался, и похоже, что LVN_ODCACHEHINT обычно правильно заполняет основной буфер и пропускает его, только если строка (в режиме отчета) частично видна.

Так что я думаю, что ответ для размера кэша: общее количество отображаемых элементов плюс одна строка отображаемых элементов (поскольку в представлениях значков у вас есть несколько элементов в строке).

Затем вы перечитали бы кэш с каждым WM_SIZE и LVN_ODCACHEHINT, если у каждого из них был разный начальный и конечный номер элемента.