Ограничения компоновщика с кодовой базой с использованием больших таблиц поиска в Visual Studio 2010

В моей работе у нас есть множество больших таблиц, в которых хранятся данные, используемые для набора многомерных непараметрических моделей. Каждый стол float массив размером от 200 000 до 5 000 000 элементов.

Сегодня я собирался выполнить обычное тривиальное обновление этой кодовой базы, обновив набор справочных таблиц, когда обнаружил, что компиляция и компоновка проекта приводят к Инкрементальный компоновщик Microsoft перестал работать, что-то, чего я раньше не видел Обратите внимание, что таблицы, которые я обновлял, увеличивались с размера около 290 000 элементов до почти 10 000 000 элементов в каждой.

Я искал и нашел методы, которые люди рекомендовали решить проблему с помощью всплывающего окна «Инкрементный компоновщик», но ничего не помогло. Я даже взял проект и интегрировал его в VS 2012, и он тоже провалился.

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

Как указывалось ранее, новые таблицы, которые я добавлял, содержат около 10 000 000 элементов каждая и значительно больше старых таблиц, которые они обновляют. Возможно ли, что компоновщик изо всех сил пытается работать с этими большими таблицами? Если так, то почему?

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

Обратите внимание, что код для каждой таблицы выглядит примерно так:

Заголовочный файл

//
// dataset1.hpp
//

#ifndef dataset1_hpp_
#define dataset1_hpp_

namespace set1 {
extern const int tableSize;
extern const float table[];
}

#endif

Исходный файл

//
// dataset1.cpp
//

namespace set1 {
extern const int tableSize = 10000000;
extern const float table[tableSize] = {
/*... Lots of Numbers ... */
};
}

1

Решение

В вашем файле .cpp вы определяете данные как extern. Зачем? Данные являются локальными для этого файла .cpp. Это выглядит странно для меня. Может быть, вам нужно:

//
// dataset1.cpp
//

namespace set1 {
const int tableSize = 10000000;
const float table[tableSize] = {
/*... Lots of Numbers ... */
};
}

Я не уверен, что это поможет, но это стоит попробовать. Может быть, вы просто обойдете эту проблему.

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

Почему вы используете VS2010? Попробуйте последнюю версию (бесплатное Community 2015) хотя бы просто, чтобы проверить, что произойдет.

0

Другие решения

Других решений пока нет …