LINUX.ORG.RU

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

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

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++. или просто напиши банальный тест и прогони его. даже если там в 1.1 раз разница - это уже повод отбросить тормозную реализацию в пользу эффективности, если речь идёт про скорость. ладно там фигня в 2 гига. а если бы были сотни терабайт? вот там и вылезают все эти недоучтённые процентики.
все мои утверждения основаны на опыте. в том числе, разработке серверных приложений, которые обрабатывают огромные потоки данных. и я не один десяток раз измеряла разные функции, реализации, разные настройки оптимизации. так что меня не надо отсылать к измерениям. я их за 20 лет сделала предостаточно.
и да, вот ещё:
C++ Format - вместо стандартного I/O:
https://github.com/cppformat/cppformat
документация:
http://cppformat.readthedocs.org/en/stable/index.html
сравнительные тесты по скорости (сравнение со стандартными и другими популярными библиотеками):
https://github.com/cppformat/cppformat/blob/master/README.rst

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

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++. или просто напиши банальный тест и прогони его. даже если там в 1.1 раз разница - это уже повод отбросить тормозную реализацию в пользу эффективности, если речь идёт про скорость. ладно там фигня в 2 гига. а если бы были сотни терабайт? вот там и вылезают все эти недоучтённые процентики.
все мои утверждения основаны на опыте. в том числе, разработке серверных приложений, которые обрабатывают огромные потоки данных. и я не один десяток раз измеряла разные функции, реализации, разные настройки оптимизации. так что меня не надо отсылать к измерениям. я их за 20 лет сделала предостаточно.

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

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++. или просто напиши банальный тест и прогони его. даже если там в 1.1 раз разница - это уже повод отбросить тормозную реализацию в пользу эффективности, если речь идёт про скорость. ладно там фигня в 2 гига. а если бы были сотни терабайт? вот там и вылезают все эти недоучтённые процентики.
все мои утверждения основаны на опыте. в том числе, разработке серверных приложений, которые обрабатывают огромные потоки данных. и я не один десяток раз измеряла разные функции, реализации, разные настройки оптимизации. так что меня не надо отсылать к измерениям. я их за 20 лет сделала предостаточно.