> Все правильно сделали. Это напрашивающаяся сама собой оптимизация для языка, нацеленного на широкое использование функционального подхода.
Тут разница в том, что это не свойство языка, ни синтаксис, ничего. Это некое абстрактное свойство рантайма, при этом оно живёт не в статусе работает/не работает. А в статусе работает хорошо/работает плохо и иногда падает по OOM.
При этом в реальности — хром вначале добавил эту оптимизацию, потом выпилил. Т.е. если кто-то заточился на эту фичу, поимел грабли. Код развалился просто так.
> то ставите себе линтер на запрет рекурсивных вызовов и нет проблем.
Рекурсия вполне может использоваться и в обычном виде, запрещать рекурсию саму по себе — это очень странно. А линтёр, определяющий хвостовую рекурсию… ну такое…
> Я даже не представляю, что значить полифиллить хвостовую рекурсию. А для class или для геттеров/сеттеров таких вопросов не возникало?
Я тоже. Но для классов — вполне себе всё полифилится. Хотя, я может неправильно термин подобрал. Наверное транспайлинг тут лучше звучит.
Ну, глубина стека не определена, да и попытка её переполнить может привести к временному эпическому потреблению памяти или браузер от ужаса прибьёт все скрипты на странице. Опасненький такой способ. :) И опять же, писать две ветки кода, одна на случай оптимизации, другая циклом — достаточно бестолковое времяпрепровождение. Раз уж написали универсальный код, зачем поддерживать код с хвостами.
Всегда хотел спросить, а что курили авторы ES6, когда включали оптимизиацию хвостовой рекурсии в стандарт? Т.е. это не возможности языка, а свойство рантайма. При этом его ещё особо и не проверить. Да и заполифиллить его нормальным образом нельзя. В результате получается фича, которую использовать нельзя, потому что на неподдерживаемом браузере всё развалится.
Вопрос не про баги :) У вас изначально была фича с подсветкой панели под цвет сайта. Вроде она достаточно фиксированная была, как придумала, так и осталась. А тут захожу на сайт Тёмы Лебедева и вижу что цвет панели меняется вместе с шапкой. Это родная фича браузера по динамической перерисовке панели в зависимости от контента, или у вас есть API для подобного и можно на своих сайтиках дёргать?
Можно утвержать, что вы патентный тролль, можно реализовать патент чуть по-другому и доказывать, что это не ваш патент, а совершенно другое решение, можно найти страну, где другое патентное законодательство и там всё делать.
А потом долго и упорно судиться, кидаясь какашками друг в друга.
Вопрос в стоимости лицензирования патента и возможной прибыли от него.
Патент как раз означает, что кто угодно может использовать данную технологию, если договорится с владельцем патента. А если владелец заломит нереальные условия, то можно судиться. Чтобы никто не заиспользовал данную технологию — надо держать её в секрете, а не патентовать.
Ну, мне поколения часто пригождались, правда больше встрявал в LOH, но и другие ситуации, связанные с «утечками» памяти тоже приходилось расследовать. Но большинству программистов нафиг не надо, да. Вопросы про это бестолковые.
Если вызвали Dispose, то финалайзер не должен вызываться. А если его забыли — то явный крэш приложения лучше, чем тихая утечкая ресурсов, которую потом отлавливать по обрывочным сведениям.
Я как-то из-за забытого диспоза при установке приложения клиенту, поехал не на поезд, а в гостиницу. И да, конечно же приложение не говорило, что кто-то забыл диспоз на 78-ой строчке в конкретном файле, и то, что забыт именно диспоз выяснилось потом.
Однако такая имплементация пула объектов — однозначно плохая идея. Как и пытаться логировать, кидать исключения, обращаться к базе и тысячи подобных действий.
Вообще, в финализаторе логировать часто хорошая идея. Потому что вызов финализатора свидетельствует о том, что разработчик забыл Dispose (Естественно, там не забыть GC.SuppressFinalize или вляпать флажок).
Смысла нет, но могу предположить что в какой-то версии вызывались разные методы или с разными аргументами. После рефакторинга остался один метод с такой странной логикой.
Ну, это как идея, чтобы оправдать автора библиотеки :)
Да, о том, что локальный резолвер всегда висит подключённый — не подумал. Правда, если оно порвётся, то будет плохо. При этом нагрузка на удалённые сервера должна быть жёсткая, держать огромное количество соединений. Но Гуглу и Клаудфлеру не жалко :)
До keep alive нужно ещё дойти. Условно говоря, если DoH через Google, а открываете какой-то другой сайт, то keep alive вообще ни при чём. Вместо двух UDP пакетов нужно 4 (лень щас считать) + небольшие томоза на сам факт SSL
Ну провалится настройка на месячном отчёте и он будет не час выполняться, а три. Раз в месяц. Зато на задачах которые выполняются каждый день и каждую минуту, всё будет лучше. В любом случае, между вариантами:
1. Использовать автонастройку, в случае проблем позвать умного DBA, который поправит
2. Нагуглить числа из интернета, в случае проблем позвать умного DBA, который поправит
3. Позвать умного DBA, который поправит сразу
Мне больше нравится вариант 1, потому что не факт, что проблемы будут, а умный DBA — это весьма дорогое существо, а ещё оно может просто сказать, купите сервер мощнее и не парьте мне мозги, что можно и без него сделать.
Добавьте ещё в список volatile, без него при многопоточности может быть забавная побочка (хотя в .NET старались её избежать ценой некоторой потери производительности).
Вот насчёт PostgreSQL я не уверен. С учётом того, что он создаёт по процессу на запрос, и у каждого процесса своё использование памяти, то тут получается или недогруз или перегруз.
У mysql лимит памяти, насколько я помню настраивается вполне неплохо и легко.
Операторов тоже дробят по префиксам. Т.е. по первым цифрам номера можно понять и оператора и регион. Т.е. из-за такого кромсания количество в реальности меньше. Список можно посмотреть на мтт
Тут разница в том, что это не свойство языка, ни синтаксис, ничего. Это некое абстрактное свойство рантайма, при этом оно живёт не в статусе работает/не работает. А в статусе работает хорошо/работает плохо и иногда падает по OOM.
При этом в реальности — хром вначале добавил эту оптимизацию, потом выпилил. Т.е. если кто-то заточился на эту фичу, поимел грабли. Код развалился просто так.
> то ставите себе линтер на запрет рекурсивных вызовов и нет проблем.
Рекурсия вполне может использоваться и в обычном виде, запрещать рекурсию саму по себе — это очень странно. А линтёр, определяющий хвостовую рекурсию… ну такое…
> Я даже не представляю, что значить полифиллить хвостовую рекурсию. А для class или для геттеров/сеттеров таких вопросов не возникало?
Я тоже. Но для классов — вполне себе всё полифилится. Хотя, я может неправильно термин подобрал. Наверное транспайлинг тут лучше звучит.
<meta name="theme-color" content="red">Буду пользоваться :)
А потом долго и упорно судиться, кидаясь какашками друг в друга.
Вопрос в стоимости лицензирования патента и возможной прибыли от него.
Я как-то из-за забытого диспоза при установке приложения клиенту, поехал не на поезд, а в гостиницу. И да, конечно же приложение не говорило, что кто-то забыл диспоз на 78-ой строчке в конкретном файле, и то, что забыт именно диспоз выяснилось потом.
Вообще, в финализаторе логировать часто хорошая идея. Потому что вызов финализатора свидетельствует о том, что разработчик забыл Dispose (Естественно, там не забыть GC.SuppressFinalize или вляпать флажок).
Ну, это как идея, чтобы оправдать автора библиотеки :)
1. Использовать автонастройку, в случае проблем позвать умного DBA, который поправит
2. Нагуглить числа из интернета, в случае проблем позвать умного DBA, который поправит
3. Позвать умного DBA, который поправит сразу
Мне больше нравится вариант 1, потому что не факт, что проблемы будут, а умный DBA — это весьма дорогое существо, а ещё оно может просто сказать, купите сервер мощнее и не парьте мне мозги, что можно и без него сделать.
У mysql лимит памяти, насколько я помню настраивается вполне неплохо и легко.