LINUX.ORG.RU

История изменений

Исправление Iron_Bug, (текущая версия) :

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

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

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

в любом случае, для скорости и больших потоков данных я не рекомендую STL, а рекомендую ACE.

Исправление Iron_Bug, :

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

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

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

Исходная версия Iron_Bug, :

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

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

вообще, любая сахаризация (упрощение) делают софт менее производительным. это просто аксиома. если кто-то делал что-то для общих задач - оно не оптимально.