Здравствуйте, Mr.Delphist, Вы писали:

MD>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL
Однозначно, обеими руками за один толстенный EXE.
Потому что он и так подгружается paging-ом постранично. Только то, что потрогали.

Этот пример показал обратное, давай другой.

Здравствуйте, CreatorCray, Вы писали:

MD>>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL
CC>Однозначно, обеими руками за один толстенный EXE.

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

CC>Потому что он и так подгружается paging-ом постранично. Только то, что потрогали.
CC>Этот пример показал обратное, давай другой.

Один большой EXE невозможно обновить частями. Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений.

Здравствуйте, Ikemefula, Вы писали:

I>А тебя не смущает, что без малого, все большие приложения написаны иначе?
Нет, мне вообще пофигу как там другие написаны.

I>Один большой EXE невозможно обновить частями.
Да в общем то и не надо.

I> Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений.
Это будет работать в настолько специфических случаях что даже не интересно. Ну и гемор по поддержке работоспособности такого аппа оправдан только жёсткими требованиями по работе 24/7 — тогда эти приседания имеют смысл.

Здравствуйте, Mr.Delphist, Вы писали:

НС>>Потому что при помощи минифаера эта проблема решается проще, а, кроме того, им же решаются и другие проблемы, которые http/2 не решаются.

MD>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL, которые подгружаются только по мере надобности (у 80% юзеров будет 20% подгруженных DLL). Вот то же самое вангую через N лет в вебе, с ростом скорости доступа и распространения протоколов типа http2. Минифаеры останутся на ролях "релизной сборки": обфусцировать и убрать лишний вес.

Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.

Здравствуйте, CreatorCray, Вы писали:

I>>А тебя не смущает, что без малого, все большие приложения написаны иначе?
CC>Нет, мне вообще пофигу как там другие написаны.
I>>Один большой EXE невозможно обновить частями.
CC>Да в общем то и не надо.

Ты похоже не в той реальности живешь

I>> Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений.
CC>Это будет работать в настолько специфических случаях что даже не интересно. Ну и гемор по поддержке работоспособности такого аппа оправдан только жёсткими требованиями по работе 24/7 — тогда эти приседания имеют смысл.

Это уже работает при каждом обновлении.

Здравствуйте, vsb, Вы писали:

vsb>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.

Давайте смотреть:

Git имени друга и товарища Л.Торвальдса — 313 DLL

TortoiseGit, простенькая приставка к Проводнику — 74 DLL

MS SQL Server — 1118 DLL

MS Office — 2 180 DLL

Камера отдаляется, чтобы взять общий план:

Visual Studio 2017 — 23 675 DLL

Windows10 — 28 485 DLL

Последнее для меня стало неожиданным открытием: VS имеет количество DLL, сравнимое со всей ОС.

Здравствуйте, Mr.Delphist, Вы писали:

vsb>>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.

MD>Давайте смотреть:
MD> Git имени друга и товарища Л.Торвальдса — 313 DLL
MD> TortoiseGit, простенькая приставка к Проводнику — 74 DLL
MD> MS SQL Server — 1118 DLL
MD> MS Office — 2 180 DLL

MD>Камера отдаляется, чтобы взять общий план:

MD> Visual Studio 2017 — 23 675 DLL
MD> Windows10 — 28 485 DLL

MD>Последнее для меня стало неожиданным открытием: VS имеет количество DLL, сравнимое со всей ОС.

Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.

Здравствуйте, Mr.Delphist, Вы писали:

vsb>>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.

MD>Давайте смотреть:
MD>

Git имени друга и товарища Л.Торвальдса — 313 DLL
MD>

TortoiseGit, простенькая приставка к Проводнику — 74 DLL
MD>

MS SQL Server — 1118 DLL
MD>

MS Office — 2 180 DLL

А как ты смотрел, по файлам или в рантайме ? В рантайме даже мелкая прога тянет на сотни мегов зависимостей.

Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.

Здравствуйте, vsb, Вы писали:

vsb>Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.

Конечно расточительство. Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.
В абсолютных числах — вместо 15 секунд получаешь задержку всего полторы.

Здравствуйте, Ikemefula, Вы писали:

vsb>>Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.

I>Конечно расточительство. Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.
I>В абсолютных числах — вместо 15 секунд получаешь задержку всего полторы.

Это да, тут прогресс отрицать нельзя.

Здравствуйте, Ikemefula, Вы писали:

I>Ты похоже не в той реальности живешь
Явно не в твоей, да.

I>Это уже работает при каждом обновлении.
Обновлении чего?

Здравствуйте, Ikemefula, Вы писали:

I>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.
Ты не путай системные либы с барахлом, которое прога таскает с собой.
Системные либы ОК, барахла же быть не должно если только это не какие то плагины. Если DLL грузится основным бинарём всегда то надо её просто влинковывать статически и не морочить никому голову.

Здравствуйте, Ikemefula, Вы писали:

I> Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.

В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).

Ты можешь сам в принципе это проверить взяв более менее посещаемый сайт и походив по нему из разных гео-локаций с http и http/2.

Здравствуйте, Anton Batenev, Вы писали:

I>> Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.

AB>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).

Что значит "встанет в очередь ожидания данных" ? Это имеется ввиду отдача файлов будет чередоваться с данными или что ?

Не совсем понятно, какой смысл сравнивать три пачки по 6 vs 1 пачка 18

AB>Ты можешь сам в принципе это проверить взяв более менее посещаемый сайт и походив по нему из разных гео-локаций с http и http/2.

Более менее посещаемые сайты отдают разные бандлы для http и http2, все что ты увидишь — разницу между разными оптимизациями. Еще и немалый шанс нарваться на разную выдачу под разные локации.

Здравствуйте, Ikemefula, Вы писали:

I>А как ты смотрел, по файлам или в рантайме ? В рантайме даже мелкая прога тянет на сотни мегов зависимостей.

По файлам

I>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.

Именно! Но не все понимают механики происходящего.

Здравствуйте, Anton Batenev, Вы писали:

AB>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).

Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?

Здравствуйте, CreatorCray, Вы писали:

I>>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.
CC>Ты не путай системные либы с барахлом, которое прога таскает с собой.
CC>Системные либы ОК, барахла же быть не должно если только это не какие то плагины. Если DLL грузится основным бинарём всегда то надо её просто влинковывать статически и не морочить никому голову.

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

Не в сто раз, как с системными, но в десять раз — запросто.

Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов

И теперь каждое обновление гита превратится из 600мб в 6гб

Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб.

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

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Anton Batenev, Вы писали:

AB>>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).

S>Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?

Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.

Здравствуйте, CreatorCray, Вы писали:

I>>Это уже работает при каждом обновлении.
CC>Обновлении чего?

Ты забыл про что мы говорим ? Если обновляется софтина, это или переинстал, или патч. В твоей реальности патч невозможен, остаётся переинстал, а следовательно — в 10 раз больше расход диска, трафика. До кучи отдельные экзешники требуют больше оперативы.

Здравствуйте, Sharov, Вы писали:

AB>>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).

S>Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?

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