| 1.1, topin89 (ok), 22:47, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 > Переделан внутренний API, строки заголовков теперь передаются в форме связанного списка.
Кто пограмотнее, объясните, какая с этого выгода.
Я искал время от времени случаи, где связный список лучше, чем указатели на массив/двустороннюю очередь, и не мог найти ничего полезней чем "ну когда нужно вставлять один контейнер в середину другого", и даже там на коротких массивах выгоды как правило не было.
Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсь.
| | |
| |
| 2.5, Онаним (?), 23:09, 21/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Быстрая вставка, быстрое удаление элемента - единственное, что могу придумать.
Больше ничего в голову не приходит. Ещё есть конечно вариант, когда суммарный размер всех указателей сопоставим с размером L1D хотя бы, а останавливаться при проходе надо максимум посерёдке - но это явно не тот случай.
| | |
| |
| |
| 4.49, Онаним (?), 22:52, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Я даже тебе объясню, почему вообще мимо тазика: реализация этих примитивов на езычге, где работа с указателями реализована через libastral (или libanal), может быть совершенно неоптимальной.
| | |
|
|
| 2.6, Онаним (?), 23:10, 21/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
С другой стороны бинарный поиск в отсортированном списке - так себе затея, т.е. это tradeoff.
Вот в жизни не поверю, что у них число вставок-удалений превышает число поисков.
| | |
| |
| 3.35, topin89 (ok), 10:41, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
> С другой стороны бинарный поиск в отсортированном списке - так себе затея,
> т.е. это tradeoff.
> Вот в жизни не поверю, что у них число вставок-удалений превышает число
> поисков.
Да даже если и превышает, ну будет массив указателей на строки размером на 10-30 строк, там вставка не будет сильно медленней, чем в списках. Из-за высокой локальности оно может ещё и быстрее оказаться.
| | |
| |
| 4.44, Онаним (?), 22:27, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Вставка в связанный список - это 2 указателя заменить, если по-минимуму. O(1)
Вставка в массив указателей - это, простите, сдвинуть N указателей. O(N)
| | |
| |
| |
| 6.53, 1 (??), 09:36, 23/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Наоборот, вырожденный случай вставлять в середину массива (это ж надо иметь отсортированный массив), а так всегда добавляется в конец.
| | |
| |
| 7.54, Онаним (?), 13:39, 23/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Вставка в конец массива (или, если быть совсем точным - всегда в одинаково отдалённую от конца массива позицию) - это O(1), не зависит от числа элементов в массиве, поэтому и вырожденный случай.
| | |
|
|
|
|
|
| 2.12, native76 (ok), 23:34, 21/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
 возможно, меньшая фрагментация памяти - возможность pre-alloc/pool блоков одинакового размера. при высокой нагрузке это может быть важно.
| | |
| |
| 3.40, topin89 (ok), 14:52, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
> возможно, меньшая фрагментация памяти - возможность pre-alloc/pool блоков одинакового
> размера. при высокой нагрузке это может быть важно.
Почитал про Pool Allocator, спасибо за место, где в связном списке больше смысла, чем в простом массиве. Но не могу понять по коду nginx, чанки ли там или просто список сам по себе.
| | |
| 3.46, Онаним (?), 22:34, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Блоки одинакового размера для содержимого хедеров?
Не, конечно это nginx, там всякое может быть. Но не верю.
| | |
|
| 2.20, Аноним (20), 01:11, 22/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Выгода от связного списка есть, только если он intrusive, как в ядре линуховом. В остальных случаях классическая реализация с указателем на следующую ноду что асимптотически так себе, что с точки зрения фрагментации кучи. Не зря же в той же жабе в 90% процентов случаев пользуются реализацией на основе массива.
| | |
| |
| 3.36, topin89 (ok), 11:07, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Выгода от связного списка есть, только если он intrusive, как в ядре линуховом.
А какая? Есть какая информация в духе "вот тут мы заменили X на linked list -- и стало слегка/гораздо быстрее", может в LKLM где-нибудь?
| | |
| 3.37, Аноним (37), 11:28, 22/06/2022 [^] [^^] [^^^] [ответить]
| –4 +/– |
Аргументация о том что так называемые "программисты на java", не знающие чем фон неймановская архитектура отличается от гарвардской, используют массивы, а не связные списки скорее говорит в пользу связных списков.
То что "макака-формошлёп" будет использовать неподходящие структуры данных понятно любому настоящему программисту на ANSI C, обильно комментирующему новости на opennet
| | |
| |
| 4.38, 1 (??), 12:29, 22/06/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ну и как поможет "программисту на java" знания о том, перемешиваются данные и код или нет, в выборе структуры данных ?
Вопрос был о том, почему перешли с массива на связный список.
| | |
|
|
| 2.28, Lucky (??), 05:23, 22/06/2022 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсь
На самом деле возможность обходить нормальные заготовки как связный список там есть давно. Просто в некоторых специфичных случаях использовались ещё и массивы (например для multi headers - когда в сообщении может быть несколько заголовков с одинаковым именем, как в случае с Set-Cookie). Из-за этого итерация по заголовкам и их значениям превращалась в квест на костылях. Теперь структуры данных привели к одному виду.
| | |
| |
| 3.34, topin89 (ok), 10:37, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
>> Раз перешли на них, должна быть хорошая причина, о которой я не догадываюсь
> Теперь структуры данных привели к одному виду.
Но зачем было в принципе список использовать? Почему не перейти к массивам? Почему в принципе был выбран именно список? А то вдруг он выбран давным-давно и теперь все хотели бы заменить, но обратная совместимость и не чини что работает.
| | |
|
| 2.32, 1 (??), 09:11, 22/06/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
Читаю ветку и душа радуется. Наконец-то что-то вменяемое, без "ненужно", раста и несоответствий в версиях питона (недавно, как раз, попал в Jinja2 версии 3.1).
Вполне себе профессиональная беседа.
| | |
| 2.47, Онаним (?), 22:38, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– | |
Пришёл на ум ещё один вариант, когда связный список эффективнее - это когда его надо часто на запись блокировать между потоками (вставка-удаление). В случае массива указателей придётся блокировать таковой целиком (или извращаться с частичной блокировкой). В случае связного списка блокировать придётся только непосредственно участвующие записи (одну или две, в зависимости односвязный или двусвязный это список).
Но это опять не про nginx.
| | |
| |
| 3.48, Онаним (?), 22:42, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну и на вставку в связный список аналогично хорошо RCU ложится, если возможность в соседнем потоке пролистать список в stale state без нового элемента не напрягает. На удаление - на любителя, прочитать удалённую запись обычно не есть гуд.
| | |
|
|
| |
| 2.17, Аноним (17), 00:59, 22/06/2022 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>Когда квик в стабильную версию добавят?
Гуглу или Фэйсбуку с их миллионами TCP коннектами понятно зачем квик.
А тебе оно зачем?
| | |
| |
| 3.23, Аноним (23), 01:50, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну я замечал, что в 2 раза быстрее сайты загружаются. Так 2 секунды где-то до появления контента, а с этим около 0.5с. В консоли смотрел-сравнивал разницу, там пишет время загрузки ресурсов.
| | |
| |
| 4.26, Аноним (26), 03:33, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
У тебя цифры не сходятся, перепроверь свои навыки в арифметике.
| | |
| |
| 5.33, another_one (ok), 09:59, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
 "быстрее сайты загружаются" и "где-то до появления контента" не одно и тоже, может в "2 раза" это до события "load".
| | |
|
| 4.39, Аноним (39), 13:11, 22/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну я замечал, что в 2 раза быстрее сайты загружаются. Так 2 секунды где-то до появления контента, а с этим около 0.5с.
Это баг в Vue, должны починить. Загрузка сайтов не должна занимать менее двух секунд.
| | |
|
| 3.25, Аноним (25), 03:24, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Quic нужен, чтобы под него маскировать любой другой UDP трафик.
| | |
| |
| |
| 5.31, Аноним (25), 08:58, 22/06/2022 [^] [^^] [^^^] [ответить]
| +/– | |
Для начала от проекта v2ray и ему подобных. Которые уже кое-что подобное сделали, только на старой версии квика.
Но для того, чтобы не светиться как новогодняя ёлка, нужно чтобы квик стал популярным.
Ну а потом придёт masque wg, и маскировка будет встроена в сам протокол.
| | |
|
|
|
|
| |
| 2.51, Онаним (?), 09:05, 23/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Тем, кто ещё на этом сидит, ещё не начал phaseout, и не готов платить за поддержку - я бы уже советовал задуматься.
| | |
| |
| 3.56, Вы забыли заполнить поле Name (?), 08:30, 24/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Тем, кто ещё на этом сидит, ещё не начал phaseout, и не
> готов платить за поддержку - я бы уже советовал задуматься.
По факту проект закончен. Так бы выпилить из него ненужное типа njs (есть nginx-lua кому надо).
| | |
|
| 2.52, Аноним (-), 09:13, 23/06/2022 [^] [^^] [^^^] [ответить]
| +/– | |
>Без Сысоева уже не то...
Без твоего ценного мнения, всё - уже то.
| | |
|
|
