Я вообще за несколько лет так и не разобрался, как пользоваться string_view. Вот принимаешь ты в параметре функции string_view, тащишь его через 10 своих методов, а в конце какой-нибудь библиотечный метод, который принимает string, и все, нужно конвертировать в string, тратить аллокацию памяти. Вот как это использовать?
Вот например релевантный пример: Stackoverflow программисты. В сообществе к ним довольно быстро выработолся иммунитет. Хотя казалось бы, что не так? На stackoverflow публикуются хорошие ответы, проверенные разными специалистами, да и вы наверняка иногда копировали ответ со stackoverflow, который сразу начинал работать. Что же с этим подходом не так?
Вот и я призываю не быть stackoverflow-оптимизатором, а задействовать специально придуманные под это дело инструменты
> инлайнинг в подавляющем большинстве случаев полезен (и я затрудняюсь придумать даже очень искусственный пример, когда это было бы не так). Для таких функций inline можно ставить вообще, всегда, по умолчанию, не думая.
Да, безусловно, какие-то утверждения будут правильными, например что инлайнинг полезен всегда. Это нормально. Если бы все утверждения какого-то конкретного оппонента были неправильными, то это было бы слишком просто: можно было бы делать все в точности до наоборот того, что говорит оппонент. И возможно, что в случае с inline вы правы, но это не отменяет общего правила: нужно мерять.
Даже по данному примеру, один из комментаторов спросил, почему тогда уж не использовать inline(always) вместо inline? Раз уж такая уверенность? Ведь даже в офф документации сказано, что inline не обязан инлайнить (да и inline(always) вроде бы тоже). Вот тут мы и видим пример веры в «божьше слово», что вставка какого-то магического слова внезапно ускорит нашу программу. От этого-то я и хочу предостеречь
> В некоторых случаях (особенно если мы обсуждаем подобные микрооптимизации) измерить эффект практически невозможно адекватным образом.
Да, я верю. У меня не было опыта в таких микрооптимизациях, поэтому тут я не компетентен. Но я подозреваю, что у большинства других программистов тоже не было. Незачем навязывать им ложные убеждения.
И все-таки, как я понимаю, вы же все равно каким-то образом замеряли выхлоп от оптимизаций? Ведь не было же такого, что вы «добавил ключевое слово к функции» и закрыли таску?
Довольно часто такое «упрямство» с нежеланием измерить профит идет сильно во вред написанию кода. Конкретно в этом случае оно может и правильно, но общая тенденция пугает.
Помню например, когда только начинал программирование, нужно было разработать многопоточное приложение. К тому времени я знал, что мьютекс — это очень медленно, и старался его не использовать. Да, я сознательно допускал в некоторых местах кода состояние гонки только ради того, чтобы не использовать мьютекс. При этом частота вызова этих функций не превышала 1000 запросов в секунду. Сейчас же я пишу программы по 100 000 rps, использующие мьютексы, и мьютекс там даже близко не является бутылочным горлышком.
И я довольно часто вижу у текущих программистов поведение, которое практиковал сам раньше. «Ну, это дорого, не будем это использовать»
Понимаете, мне не за себя. Мне за державу обидно. Обидно видеть, как программисты вокруг считают, что достаточно добавить какое-то слово, заменить одну функцию на другую и все станет волшебным образом быстрее. Хотя вроде бы это так легко — просто взять и проверить. Измерение производительности — это одна из немногих (а может и вообще единственная) область программирования, где правильного результата можно добиться обычным измерением. Да, не всегда это просто, и тут тоже есть подводные камни разной степени сложности, но почему бы не прививать культуру «хочешь ускорить — замерь»? Оптимизация — такой же важный этап работы программиста, как и написание кода, зачем его всеми силами избегать?
Ну если вы действительно смотрите ассамблер и понимаете, как инструкции ассамблера матчатца на производительность, то это вполне себе альтернатива бенчмаркинга. Но все равно без должных измерений это никуда не годится
Вот удивляюсь всегда таким людям как вы. Замеры времени — это одна из немногих метрик в программировании, которая поддается боле-менее безболезненному измерению. Но нет, все равно люди предпочитают пользоваться какими-то советами, возникшими хрен знает откуда, хотя казалось бы, чего проще, взять да померять
Если вы купите "опасное" устройство, то тоже можете делать с ним что угодно? Например, если купите 1000 "ртутных" ламп, имеете ли полное право их разбить? Если купите килограмм порошка tide, имеете ли право сделать из него бомбу? (Или из чего ее обычно делают)
До сих пор впадаю в ступор, когда вижу код наподобие
unsigned long long = -1;
Я ведь правильно понимаю, что это эквивалентно
unsigned long long = -1ull;
?
Тоесть если к результирующему значению прибавить 1, то получится 0?
В статье об этом сказано, но не очень понятно
Чего? Вообще, под каллиграфией я имел в виду не искусство каллиграфии, а способность выразить словами на бумаге хоть что-то читаемое посторонними людьми. Я например, не имею даже такого навыка
Я вообще за несколько лет так и не разобрался, как пользоваться string_view. Вот принимаешь ты в параметре функции string_view, тащишь его через 10 своих методов, а в конце какой-нибудь библиотечный метод, который принимает string, и все, нужно конвертировать в string, тратить аллокацию памяти. Вот как это использовать?
А это само получается. Если бы об этом знать всегда заранее…
Это еще "развитие" называется
Чтобы испытать чуть меньше разочарования от сделанного
Вот и я призываю не быть stackoverflow-оптимизатором, а задействовать специально придуманные под это дело инструменты
Да, безусловно, какие-то утверждения будут правильными, например что инлайнинг полезен всегда. Это нормально. Если бы все утверждения какого-то конкретного оппонента были неправильными, то это было бы слишком просто: можно было бы делать все в точности до наоборот того, что говорит оппонент. И возможно, что в случае с inline вы правы, но это не отменяет общего правила: нужно мерять.
Даже по данному примеру, один из комментаторов спросил, почему тогда уж не использовать inline(always) вместо inline? Раз уж такая уверенность? Ведь даже в офф документации сказано, что inline не обязан инлайнить (да и inline(always) вроде бы тоже). Вот тут мы и видим пример веры в «божьше слово», что вставка какого-то магического слова внезапно ускорит нашу программу. От этого-то я и хочу предостеречь
> В некоторых случаях (особенно если мы обсуждаем подобные микрооптимизации) измерить эффект практически невозможно адекватным образом.
Да, я верю. У меня не было опыта в таких микрооптимизациях, поэтому тут я не компетентен. Но я подозреваю, что у большинства других программистов тоже не было. Незачем навязывать им ложные убеждения.
И все-таки, как я понимаю, вы же все равно каким-то образом замеряли выхлоп от оптимизаций? Ведь не было же такого, что вы «добавил ключевое слово к функции» и закрыли таску?
Помню например, когда только начинал программирование, нужно было разработать многопоточное приложение. К тому времени я знал, что мьютекс — это очень медленно, и старался его не использовать. Да, я сознательно допускал в некоторых местах кода состояние гонки только ради того, чтобы не использовать мьютекс. При этом частота вызова этих функций не превышала 1000 запросов в секунду. Сейчас же я пишу программы по 100 000 rps, использующие мьютексы, и мьютекс там даже близко не является бутылочным горлышком.
И я довольно часто вижу у текущих программистов поведение, которое практиковал сам раньше. «Ну, это дорого, не будем это использовать»
> увидеть есть там bottle neck или нет и лишь в случае сомнений уже сделать бенчмарк
Почему тогда не наоборот, увидеть bottle neck и соптимизировать? Зачем эта предварительная оптимизация?
Я ведь надеюсь под «знает» понимается «написал кучу бенчмарков и замерил профит с разных путей выполнения»?
Ну вот, случайно задел пальцем и получился минус. Теперь не знаю, как вернуть
Если вы купите "опасное" устройство, то тоже можете делать с ним что угодно? Например, если купите 1000 "ртутных" ламп, имеете ли полное право их разбить? Если купите килограмм порошка tide, имеете ли право сделать из него бомбу? (Или из чего ее обычно делают)
unsigned long long = -1;
Я ведь правильно понимаю, что это эквивалентно
unsigned long long = -1ull;
?
Тоесть если к результирующему значению прибавить 1, то получится 0?
В статье об этом сказано, но не очень понятно
А вы на какие ходили?
О том, что существуют какие-то там курсы каллиграфии, я только сегодня узнал