orefkov писал(а) 18. Октября 2007 :: 13:03:

У меня под рукой только небольшая база. Для номенклатуры результаты такие:
Цитата:


Тестовый код:

Процедура Сформировать2 ()
	ЗагрузитьВнешнююКомпоненту ("1cpp.dll");
	Подключение = СоздатьОбъект ("OLEDBData");
	Подключение.Соединение (Шаблон ("Provider=VFPOLEDB.1; Mode=ReadWrite;
		|Data Source=[КаталогИБ ()];"));

	Команда = Подключение.СоздатьКоманду ();
	т1 = _GetPerformanceCounter();
	ТЗ = Команда.ВыполнитьИнструкцию ("select * from $Справочник.Номенклатура");
	т2 = _GetPerformanceCounter();
	Сообщить("Строк = " + тз.КоличествоСтрок() + " время " + (т2 - т1));
	ТЗ.ВыбратьСтроку ();
КонецПроцедуры
 

Uzhast писал(а) 18. Октября 2007 :: 12:48:

В SP2 vfpoledb.dll v9.0.00.5815.

orefkov писал(а) 18. Октября 2007 :: 13:03:


SQLLite
Очень странные результаты.
Локально 602 (было и 395)
К базе на сервере 9465 !!!
хотя по коду от этого не должно зависеть.

Fox значения одинаковые для локального и серверного вариантов
516 (было и  374 )

kiruha писал(а) 18. Октября 2007 :: 14:04:

Интересно, а действительно, что может вызывать такую разницу в сетевом и локальном варианте? Бродит некая мысля по этому поводу... Скажем, VFP наверняка использует Memory Mapped файлы для доступа. Вот и думаю, а что если 1С использует не MMF, а обычное чтение файла через вызовы API? Тогда получается, что для Фокса данные из сети подкачиваются большими блоками (страницами), а для 1С маленькими порциями по одной записи. Может это и вызывает тормоза?

Uzhast писал(а) 18. Октября 2007 :: 15:47:


Я тестировал в Fox е доступ из памяти - аналог теста orefkov. Т.е. разницы(для Fox) и не должно быть. При чтении файлов по сети естественно разница возникает и достаточно существенная для больших файлов. В случае компоненты под sqllite - что то там видимо неправильно работает с виртуальными таблицами (?) .

Uzhast писал(а) 18. Октября 2007 :: 16:00:


Штатные методы объектов можно переписать на Fox. Скорость местами даже быстрее, чем обычные прямые запросы, т.к. автоматически подбираются подходящие индексы.

kiruha писал(а) 18. Октября 2007 :: 18:31:

То, что переписать можно - это понятно. Вопрос в другом. Насколько это позволит сделать переписывание dbeng32? Может быть, это настолько низкий уровень, что практически не позволяет управлять процессом обработки данных?

А дайте код работы с dbeng на посмотреть, а?

Скажу сразу, в работе с dbeng32 я еще не специалист. Пока просто пытаюсь освоить методом научного тыка.
Но что сразу хочется отметить - вряд ли ее можно переделать на что-то действительно клиент-серверное, потому как идеология работы в корне различается. dbeng это - выбрал таблицу, индекс, и пошел first, last, seek, next, prev. А клиент-сервер - это запросы.

Теперь по тестам:
Таки скачал я ночную сборку 2.5, OLE DB VFP провайдера, тестю.
Вот у меня результаты простого селекта без типизации результата, запускалось несколько раз.
Тест локальной базы:

SQLite: Строк = 16961 время 2469
OLE DB FP: Строк = 16961 время 2104
SQLite: Строк = 16961 время 1846
OLE DB FP: Строк = 16961 время 1889
SQLite: Строк = 16961 время 1861
OLE DB FP: Строк = 16961 время 1936
SQLite: Строк = 16961 время 1746
OLE DB FP: Строк = 16961 время 1814


Тест той же базы при сетевом доступе:

SQLite: Строк = 16961 время 7372
OLE DB FP: Строк = 16961 время 5289
SQLite: Строк = 16961 время 5311
OLE DB FP: Строк = 16961 время 4883
SQLite: Строк = 16961 время 5000
OLE DB FP: Строк = 16961 время 5009
SQLite: Строк = 16961 время 5167
OLE DB FP: Строк = 16961 время 5052

Результаты двух способов доступа сопоставимы.
Но по SQLite у меня есть еще запас по оптимизации.
Хотя, возможно, я не умею фокса как следует готовить.

Прикладываю как обычно тестовую обработку и слегка правленную ВК.