ИзопропилandreybsА конструкторы тоже хранятся в памяти, как обычные методы в общем сегменте кода?
да, хранятся так же.


"Лишний" указатель - вряд ли является узким местом в данном проекте.
память, выделяемая C-шным malloc - тоже имеет накладные расходы - на выравнивание данных, на хранение длины выделенного блока.

Да, с malloc есть проблема. На основании этой статьи я решил построить все на базе динамического массива (std::vector), содержащего структуры (включая вложенные динамические массивы ссылок) с описанием элементов системы. В моем случае интересует максимально быстрый последовательный доступ к элементам массивов и добавление элементов в конец массивов. Для уменьшения фрагментированности памяти я планирую предварительно отсортировать средствами СУБД импортируемые из БД данные со структурой системы. Как-то так будем бороться с недостатками malloc...

Скорость ADO не радует при возврате блока данных в sql-сервер. Судя по профайлеру, если передавать строки через объект рекордсета, то данные передаются с помощью курсора. Если передавать напрямую через команду insert с параметрами, то получается быстрее, но все равно не то. Нужен либо BULK Copy, либо возвращаемая табличная переменная. Решил таки использовать шаблоны OLEDB (sqloledb + atldbcli) вместо ADO.

Чертов OLEDB задрал уже... Мало того, что в документации msdn нет нормальных примеров, так баг на баге сидит. Вот, сейчас борюсь с некорректной работой удаления CDynamicStringAccessor без параметров . И оказывается, это далеко не единственный косяк в библиотеке. Я вот чего не пойму - я ставил vs2012 ultimate, на нее даже какие-то апдейты накатились. Но баги с OLEDB остались, хотя о них известно давно (судя по статьям). Может нужно какой фикс на vs2012 скачать, не в курсе?

И еще вопрос по специфике использования oledb с mssql. Почему то мне не удается выполнить неподготовленную команду. CCommand.Open выдает ошибку "команда не подготовлена". Если команду подготовить, то в профайлере видно "exec sp_prepexec ... exec sp_unprepare", а я хочу "exec sp_executesql", который в моем случае будет быстрее. ADO выполнял команды без prepare именно через sp_executesql. Непонятно, как добиться этого же с помощью CCommend.

Изопропилandreybs,

если борьба за последние микросекунды - лучше использовать хранимые процедуры

Это не поможет. Объясню. Потери возникают в момент возврата рассчитанных данных в sql-сервер. Так уж получается, что для серьезной задачи приходится возвращать порядка 1000 строк за каждый такт вычислений. А при той скорости вычислений, которой мне удалось добиться (на тестовой задаче: ~250тыс вычислений в секунду, ~10тыс вычислений на такт, ~25тактов/сек) эта чертова вставка жрет слишком много времени.

Так вот, сейчас происходит вставка данных в лоб при помощи приготовленной параметризированной команды insert, которая вызывается 1000 раз в каждый такт, т.е. 25тыс вставок в секунду. Оптимизатору sql будет все равно - будет ли делать вставку команда insert или хранимая процедура с параметрами, главный минус - каждая вставка порождает одну транзакцию, которая фиксируется в журнале транзакций. Я хочу использовать BULK INSERT (интерфейс FastLoad из OLEDB), что должно либо сильно ускорить вставку, т.к. сам механизм BULK INSERT работает на физическом уровне и каждая вставка выполняется за рамкой транзакции.

Думал это реализовать через OLE DB, но серьезно увяз в нюансах его работы. Сейчас попробую еще одну идею - скрестить ADO и шаблоны OLEDB. В некоторых классах ADO есть выход на DataSource. Можно попробовать за него зацепиться и создать класс расширения ADOBulkInsert. Тогда сохранится удобство обертки ADO (на ней все прекрасно работает) и добавится новая возможность.

ИзопропилandreybsЭто не поможет.
а к чему тогда слёзы по sp_prepexec ?
andreybsЯ хочу использовать BULK INSERT
правильно.

А закончится заменой СУБД

sp_prepexec нужен не всегда. Он нужен только для повторяющихся команд. Для одиночных команд select лучше использовать sp_executesql. Как управлять этим из ADO - мне понятно, но повторить это в OLEDB у меня не получилось, примеров я не нашел, а пробовать готовые библиотеки и копаться в их исходниках просто нет не времени ни желания.

Заменой СУБД не закончится - в ней достаточно сложная обработка больших массивов статистических данных. Реализовать такое в программе мне не под силу в разумные сроки. Так что буду добивать вариант выноса вычислений за пределы СУБД. Ведь все получилось, остался один маленький шажок с BULK INSERT через OLEDB...

Уф, ну и намучился я с этим капризным OLE DB. Короче, может кому понадобится, вот кусок кода на C++, как подключиться к открытому коннекту ADO Connection и получить доступ к интерфейсу OLE IRowsetFastLoad (он же BULK INSERT) для дальнейшей массовой вставки данных в таблицу... Это как раз то, что мне не хватало в ADO.




Если кому нужно, то от сюда можно дернуть исходники по самой вставке данных

Обрабатывая логику программы, внезапно обнаружил, что на каждую вставку pFastLoad->InsertRow(..) в sql-сервер уходит команда BULK INSERT. Вроде не должно быть такого - должен блоками вставлять: (SSPROP_FASTLOADOPTIONS, L"ROWS_PER_BATCH=10000"). Может причина в pFastLoad->Commit(FALSE), который идет сразу за pFastLoad->InsertRow(..)? В примерах именно так написано, но может Commit(FALSE) не надо трогать до окончания вставки, а в конце сразу сделать Commit(TRUE)?

andreybsОбрабатывая логику программы, внезапно обнаружил, что на каждую вставку pFastLoad->InsertRow(..) в sql-сервер уходит команда BULK INSERT. Вроде не должно быть такого - должен блоками вставлять: (SSPROP_FASTLOADOPTIONS, L"ROWS_PER_BATCH=10000"). Может причина в pFastLoad->Commit(FALSE), который идет сразу за pFastLoad->InsertRow(..)? В примерах именно так написано, но может Commit(FALSE) не надо трогать до окончания вставки, а в конце сразу сделать Commit(TRUE)?

Так и есть - Commit всегда вставляет в базу вне зависимости от принимаемого параметра. Нужно делать Commit(true) только в самом конце вставки. Сам спросил - сам ответил... :)

В итоге реализовал одну и туже задачу в трех средах. Произвел замеры скорости вычислений простенькой нейросети:

результаты: (вычислений/сек)
СУБД t-sql 540
exe C++ 48000
clr C# 72000

В общем, это какой-то провал.... C# почти в два раза быстрее. Я не понимаю, почему так получилось - алгоритмы одни и те же, реализация самих вычислений проста и одинаково реализована. Буду думать...

beg-in-erandreybsрезультаты: (вычислений/сек)
СУБД t-sql 540
exe C++ 48000
clr C# 72000

В общем, это какой-то провал.... C# почти в два раза быстрее. Я не понимаю, почему так получилось - алгоритмы одни и те же, реализация самих вычислений проста и одинаково реализована. Буду думать...
ну вот , оптимизация на лицо. скорость выросла в 100 раз. по сравнению с t-sql.
а что до того, что якобы C# быстрее ...так это по тому например, что оптимизатор в С# очень неплохой. убери галочку оптимизировать код и сравни )))
тут надо сравнивать ассемблерный код.
чудес не бывает. увы.

Ну, я не сомневался, что C# не плох, но везде пишут, что С++ быстрее раза в два... Я хочу докопаться до причины обратной зависимости в моем случае. Что-то тут явно не то... Сделал отдельную ветку по оптимизации C++ программы . Дальше для ускорения хочу попробовать использовать технологию C++ Accelerated Massive Parallelism для вычислений на базе процессора видеокарты.

Алексей КandreybsВ дотнетах два основных тормоза:
1. Контроль типов при преобразовании от базового класса к потомку.
2. Контроль границ массивов - основной тормоз.

Есть ещё автоматическое управление памятью, но там не всё так однозначно.

Делай выводы...

1. учтено. в повторяющихся операциях исключено.
2. учтено. считывание границ один раз за цикл.

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


Еще одна фишка - вставил счетчики на базе статических внешних Stopwatch во внутренние функции в проге на C# и производительность упала в 10 раз!!! Надо искать другие варианты точного расчета времени выполнения. Буду экспериментировать...

beg-in-erandreybsБуду экспериментировать...
Укорения в 100 раз мало?

Мало. :)
Я хочу добиться производительности на С++ в два раза выше, чем на С#, а после еще ускорить за счет параллелизма вычислений через GPU.

andreybsВ итоге реализовал одну и туже задачу в трех средах. Произвел замеры скорости вычислений простенькой нейросети:

результаты: (вычислений/сек)
СУБД t-sql 540
exe C++ 48000
clr C# 72000

В общем, это какой-то провал.... C# почти в два раза быстрее. Я не понимаю, почему так получилось - алгоритмы одни и те же, реализация самих вычислений проста и одинаково реализована. Буду думать...

Причина тормознутости проги на C++ была в неверных настройках компилятора. На деле С++ получился в 14 (!!!) раз быстрее С#: 2142000 против 125000 вычислений/сек. Вот это дело! Теперь я не жалею, что перевел все на С++...