Конечно, ещё требуется детальное исследование, нужно провести профайлинг при выполнении отчётов. Предположительно, замедление скорости отчёта связано с использованием строковых функций, которые в WINE медленнее из-за реализации через Unicode? Например, используются эти: 0028:Ret KERNEL32.lstrcmpiA() retval=ffffffff ret=20091cda Нужен тест по измерению их производительности.
Стоит прочитать всем, кто хочет заниматься оптимизацией: http://www.rsdn.ru/article/philosophy/Optimization.xml
Написал простенький тест на lstrcmpi(), где 1000 раз сравниваются друг с другом 2 массива по 6 различных строк в каждом. Промежуточные средние результаты (5 запусков друг за другом): Винда: 27,6 ms. Wine: 15.8 ms.
*не 1000, а 5000
Пока непонятно что оптимизировать.
Если оптимизировать по нашему плану (не переводить строки в юникод), то выигрыш составляет - вместо 19 мс - 5 мс.То есть на порядок.
Сделал оптимизацию. Запускал в бутылке с 1с77-25 с целларовским вайном и со своим. Тестировал на БД объёмом 1 ГБ. Отчёт - Журнал - ордер. Временной интервал - 1 год. Мой ванй:4,02 (минутыб секунды) Cellar: 5,25 Итого: Выйгрыш 30 %. Подготавливаю патч и добавляю в нашу cvs.
Считаю что другие функции lstr* уже написанны в оптимальной форме. Т.к там отсутствуют преобразования в юникод и выделение памяти. lstrcmpi оптимизировал. Так что багу закрываю.
Отлично. Хороший результат. Теперь у нас не будет отставания от винды. Похоже у них тоже так сделано :) Для всех ли локалей сделаны таблицы? Надо для русской, белорусской, украинской... Вроде всё.
Тестирование не показало отличие в скорости. Возможно где-то проблема... Предлагаю разместить тест на скорость в репозитории wine-etersoft-devel, каталог sort.
Считаем, что всё что возможно мы уже оптимизировали.
