Кэширование в высокопроизводительном финансовом приложении

Я пишу приложение, целью которого является оптимизация торговой стратегии. Для простоты предположим только, что у нас есть торговая стратегия, которая гласит «вход здесь», затем другая, которая говорит «выход здесь, если в сделке», а затем позволяет иметь две модели: одна говорит, какой риск мы должны принять (как много мы теряем, если находимся не на той стороне рынка), а другой говорит, какую прибыль мы должны получить (то есть, какую прибыль мы получим, если рынок согласится).

Для простоты я буду называть исторически реализованные сделки тиками. Это означает, что, если я «войду в тик 28», это означает, что я вступил бы в сделку во время 28-й сделки в моем наборе данных по цене этой сделки. Тики хранятся в хронологическом порядке в моем наборе данных.

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

Поэтому я перебираю массив сделок и рассчитываю exitTick [i] = min (exitTickByStrat [i], exitTickByLoss [i], exitTickByProfit [i]). И весь процесс чертовски медленный (скажем, я делаю это 100 миллионов раз). Я подозреваю, что ошибки кэша являются основной причиной. И вопрос: можно ли это сделать как-нибудь быстрее? Я должен перебрать 4 массива некоторой нетривиальной длины. Одно из предложенных мною предложений — сгруппировать данные в кортежи по четыре, то есть иметь один массив структур, таких как (entryTick, exitOnStrat, exitOnLoss, exitOnProfit). Это может быть быстрее из-за лучшей предсказуемости кэша, но я не могу сказать точно. Почему я до сих пор не проверял это, так это то, что инструментальные профилировщики как-то не работают для двоичных файлов выпуска моего приложения, в то время как выборочные профилировщики кажутся мне ненадежными (я пробовал профилировщик Intel).

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

Редактировать:
Большое спасибо всем. Я попытался максимально упростить свой первоначальный вопрос, отсюда и путаница. Просто чтобы убедиться, что он читабелен — цель означает предполагаемую / реализованную прибыль, стоп — предполагаемую / реализованную прибыль.

Оптимизатор — грубой силы. Итак, у меня есть несколько настроек strat (например, периоды индикатора, что угодно), затем min / max breakEvenAfter / breakEvenBy и затем формулы, чтобы дать вам значения стоп / цель в тиках. Эти формулы также являются объектами оптимизации. Следовательно, у меня есть структура оптимизации, как

for each in params
{
calculateEntries()
for each in beSettings
{
precalculateBeData()
for each in targetFormulaSettings
{
precalculateTargetsAndRespectiveExitTicks
for each in stopFormulaSettings
{
precalulcateStopsAndRespectiveExitsTicks
evaluateExitsAndDetermineImprovement()
}
}
}
}

Поэтому я пересчитываю как можно больше и вычисляю только то, что мне нужно. И из 30 секунд вычисление тратит 25 секунд в функцииifyExitsAndDetermineImprovement (), которая выполняет то, что я описал в исходном вопросе, то есть выбирает min (exitOnPattern, exitOnStop, exitOnTarget). Причина, по которой мне нужно вызывать функцию 100 раз, заключается в том, что у меня есть 100 миллионов комбинаций всех параметров вместе. Но в течение последнего цикла for изменяется только массив exitOnStops. Я могу опубликовать код, если это поможет. Я благодарен за все комментарии!