Например, я написал свой архиватор (exe, который ещё пользователь запускает вместо исходников). Объясните, пожалуйста, как нужно проверять скорость и эффективность сжатия для архива размером 10 гигабайт. Сколько лет нужно тестировать архиватор по вашей книге, сколько жёстких дисков надо сломать для этого?
либы, которые заточены под бенчмарки, а не принтфы
А пользователям программ тоже специальные либы юзать вместо монитора?
Другое дело, что один прогон даёт статистически незначимый результат. Однако несколько прогонов подряд дают горячий результат, который, строго говоря, следует игнорировать. А кэш ваши либы тоже чистить будут, или надо сначала пропатчить их исходники?
Alex_87, Чтобы вы поняли, что не понимаете. Дело в том, что мы на разных уровнях понимания: для вас интернет - это магия, а для меня это вполне чёткие, конкретные и понятные протоколы + оборудование + код.
Но вы ведь задаёте вопрос уровня 5-летнего ребёнка игнорируя "слишком абстрактно, сложно материализующее в голове понятия". Поэтому и получаете ответ для 5-летнего ребёнка в стиле " подрастёшь и узнаешь".
Скажем, есть к примеру хост-провайдер, предоставляющие место для сайта. Он же использует тот же http запрос для отдачи нам нужных файлов?
никогда не понимал подобных вопросов. Зачем писать полный бред домохозяйки на профильном форуме специалистов!? Вы бы ещё написал про искусственный интеллект или цифровой рубль (это как бы примеры некорректных вопросов).
Иерокопус Таманский, не согласен с вами. Держать кубер не проще обычного докера. А если всё это дело уже в каком-нибудь стандартном облаке, то там вообще одним конфигов всё разворачивается и масштабируется.
mayton2019,
Нет, данные читались с SSD, затем обрабатывались в RAM. Тут сработал именно планировщик ос/фс. Идея в том, что умные дяди сами подбирают размер буфера и частоту fsync. А потоки исключительно, чтобы сообщить им о наличии данных (по сути, это дробление большой очереди на несколько малых).
mayton2019, я записывал много данных в несколько архивов на стареньком HDD 2010 года. Сначала использовал 1 поток, потом 8, затем 60 (это максимум для windows python). В результате время уменьшилось с ~30 минут до ~1 минуты.
Лично у меня сработало два нюанса (я писал на питоне):
1) драйвер файловой системы/операционной системы/диска эффективнее кэширует и записывает несколько поток, чем ручная программа
2) Не нужно использовать малый промежуточный буфер. Если на компьютере 16 Гб RAM, то и на буферы записи имеет смысл выделить ~ 10 Гб. Ну в крайнем случае 100 Мб на буфер.
Правильный ответ - бесконечно малый шаг или много меньше ошибки интерполяции. Скажем, 1e-9 - достаточный шаг, чтобы ошибка не превышала 1e-6. Ну или по формуле exp(1)-exp(1-h)=1e-6 → 3.68e-7.
AshBlade, При реинициализации вам, по сути, необходимо частично "очистить", а затем частично проинициализировать сокет. Эти операции сэкономят немного памяти и времени, но придётся разбираться в исходниках System.Net.Sockets.Socket.
Вам нужно будет посмотреть, какие поля требуется "очистить", а затем какие поля следует вернуть в исходное состояние. Например, необходимо будет убрать флаг соединения и код ошибки, но оставить адрес соединения. В общем и целом, это выглядит как нецелесообразная микрооптимизация.
Jaish, это очень ситуативно. Например, на одном сервере хранятся уже около 15 лет. На другом не больше месяца. Но в среднем, у нас просто есть бесконечное облако, которое пополняется новыми жёсткими дисками по требованию.
Например, я написал свой архиватор (exe, который ещё пользователь запускает вместо исходников). Объясните, пожалуйста, как нужно проверять скорость и эффективность сжатия для архива размером 10 гигабайт. Сколько лет нужно тестировать архиватор по вашей книге, сколько жёстких дисков надо сломать для этого?