Я использую множественное наследование с расширенной сериализацией. вместо того, чтобы делать
boost::serialization::base_object< Connection<T> >(*this)
boost::serialization::base_object< Collection<C> >(*this)
я делаю
template<typename ArchiveT>
void save(ArchiveT& arc, const unsigned version) const{
//both Connection<T> and Collection<C> are Base Classes
Connection<T>::save(arc, version);
Collection<C>::save(arc, version);
}
и это работает. Так что, два из них — это одно и то же? или в этом есть какой-то вред? я должен изменить этот код?
{Эта вещь была закодирована давно. Поэтому я забыл, почему я так закодировал. может быть, я не знал base_object
в это время}
Я сериализирую огромный набор данных (~ 1,6 ГБ). Когда я сериализуюсь, я вижу, что процесс сериализации занимает много памяти и преодолевает барьер в 3 ГБ. Я пытался комментировать код сериализации, и это занимает < 50 МБ памяти. Так что же делает сериализация захватом такой большой памяти?
Вы должны изменить свой код и сериализовать базовые классы через base_object<>()
,
От документация:
[…] Обратите внимание, что это НЕ то же самое, что вызов функции сериализации базового класса. Может показаться, что это работает, но обойдёт определенный код, используемый для отслеживания объектов и регистрации основанных на базе связей и другой бухгалтерии, которая требуется для системы сериализации, чтобы она функционировала так, как задумано. По этой причине все функции-члены сериализации должны быть закрытыми.
Дополнительное потребление памяти, вероятно, вызвано отслеживание объекта.
Если отслеживается большое количество объектов, потребление памяти может значительно возрасти во время сериализации.
Если априори известно, что никакие значения указателя не дублируются, издержки, связанные с отслеживанием объектов, могут быть устранены путем соответствующей установки свойства сериализации класса отслеживания объектов.
Если вам не требуется отслеживание объекта, вы можете отключить его с помощью:
BOOST_CLASS_TRACKING(the_class, boost::serialization::track_never)
Других решений пока нет …