anetto1502

1. Фиксируйте всё. Абсолютно любые задачи, идеи и прочие мелочи, всё должно быть записано. Разгрузите оперативную память, не храните ничего в голове. Голова нужна, чтобы думать, а не помнить.

2. Все задачи храните в одном месте, я предлагаю для этого таск-менеджер. Таск-менеджер должен быть единым источником всего. Никаких задач, записанных где-то ещё. Прежде всего ты сам и твоя голова должна доверять этому источнику информации. Не должно быть такого, что не уверен, где записал задачу или записал ли вообще. Привычка всё фиксировать в одном месте положительно влияет на подсознание, становится сильно спокойнее.

3. Задачи нужно декомпозировать до небольших подзадач. Идеальная задача содержит действие, чтобы сразу можно было приступить. Как правило, плохо сформулированные задачи никогда не берутся в работу – вы просто не знаете, как к этой задаче приступить, и этот страх парализует желание начать выполнять задачу. Про правильную декомпозицию задач и почему это важно подробнее писал тут. В результате декомпозиции у большой задачи появляется небольшой первый шаг, после выполнения которого легко планировать следующий.

4. На мой взгляд, приоритеты обычно не нужны. Иногда, редко, можно какой-то задаче накинуть приоритет, чтобы её было видно лучше. Но я предлагаю способ, при котором на день задач не так много и можно легко понять, что нужно брать в работу. К тому же, если есть две задачи с высоким приоритетом, то какая более приоритетная?

Как начать в первый раз

Нужно выгрузить все задачи из оперативной памяти, чтобы разгрузить голову. Потом мы это всё дело оцифруем. Даже если вы уже используете таск-менеджер, то с помощью гайда ниже вы можете пополнить его упущенными задачами. Предлагаю действовать следующим образом.

Готовимся:

1. Где-то раздобыть хорошее настроение, свободную голову и расслабиться.

2. Взять ручку и бумажку, а лучше несколько.

3. Освободить час времени, хотя кому-то может хватить и 15 минут.

4. Выключить все мобилки, любые нотификации, закрыть всю технику, убрать все отвлекающие факторы.

Действуем:

1. Садимся в удобном месте, засекаем время (зачем трекать время?) и начинаем писать ааааабсолютно все мысли, которые приходят в голову: там будут задачи, идеи, напоминалки вроде "полить цветы", всё-всё-всё. Пишем и пишем. Когда я такое первый раз делал, исписал 4 листа А4.

2. Всё записанное надо оцифровать. В предлагаемом мной методе вносим всё в папку inbox, о порядке работы с ней расскажу ниже. По сути, это входная точка вашего таск-менеджера, откуда я ежедневно разгребаю задачи.

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

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

Устройство пространства

Теперь поговорим о структуре организации наших задач. Реализовать подобное, думаю, можно в любом таск-трекере. Пространство задач состоит из разделов, тегов и фильтров: – разделы позволяют разбить задачи на группы; – теги я применяю для структурирования задач, причём теги работают вне разделов; – фильтры как способ отобрать нужные задачи и работать только с ними, центральная фича в моём ведении дел.

Разделы, теги и фильтры могут быть весьма индивидуальными, ниже я делюсь своими.

Разделы:

Стараюсь обходиться минимальным количеством разделов: inbox для входящих задач/мыслей/всего подряд, work для оформленных рабочих задач, meeting для созвонов и встреч и wiki для заметок, мыслей и идей. Подробнее о разделах:

1. inbox (входящие) – это вход в ваше пространство. Место, куда записывается абсолютно всё, никак не обработанное. Идеи, задачи, микро-таски, что-то на подумать, ответить позже – всё сбрасываем сюда, чтобы не упустить. В дальнейшей работе целью будет ежедневно опустошать этот раздел.

2. work (работа) – раздел, где содержатся оформленные, понятные рабочие задачи.

3. meeting (встречи) – онлайн созвоны или оффлайн встречи являются особым типом задач, в которых ты привязан к конкретному времени и где нужно коммуницировать с другими людьми. Бывает нерабочие дела, попадающие в рабочее время (например, поход к врачу) удобно оформлять в виде встречи.

4. wiki (база знаний) – некоторое пространство для заметок, мыслей, хранения статей. Тут пока ничего не порекомендую, очень индивидуально выходит. Можно отдельный рассказ строить о том, как организовать базу знаний. Многие для таких целей используют отдельные приложения, например, Obsidian с разухабистым функционалом или Anytype. Я пока и это храню в TickTick, но в поиске другого решения.

Теги:

Часть тегов появились или стали более актуальны, когда у меня появились менеджерские обязанности и люди в подчинении. Плюс я пришёл к удобному именованию тегов на английском языке из соображений скорости работы. Ввожу решетку и сразу начинаю писать тег, не переключая язык.

• awaits_me (ожидает_меня) – супер-важный тег, им помечаю задачи, которые блокируют чью-то работу. Стоит делать такие задачи в первую очередь, так как кто-то сидит и ждёт от меня результат, чтобы продолжить выполнение какой-то своей задачи.

• assigned_control (поручено_контроль) – использую, когда кому-то поручил задачу и жду результата, чтобы дальше использовать артефакт работы. Иногда использую для контроля выполнения не очень больших заданий. В таком случае, сразу после постановки задачи закидываю себе задачу по контролю на через условно неделю, чтобы проверить.

• ping (напомнить) – использую для напоминаний в личных целях, например, напомнить что-то жене. На работе я рассчитываю, что сотруднику ничего напоминать не нужно. Хотя бывают случаи, когда команда работает в запаре. Тогда явно себе помечаю, что хоть Коле задачу я выдал, но нужно бы напомнить, а то у него сейчас и так OOM (out-of-memory). Причём выдать задачу Коле означает: создать задачу для Коли в командном таск-менеджере, прописать в задаче её особенности, зафиксировать время выполнения. При этом для контроля выполнения у нас есть прекрасный тег assigned_control, который был выше.

• now (сейчас) – таким иногда помечаю те микро-таски, которые можно сделать меньше, чем за 5 минут. Их полезно делать сразу, чтобы они не висели, и быстренько их закрывать.

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

Фильтры:

Когда задачи разложены по разделам и помечены тегами (как всё разложить расскажу ниже), нам надо в них ориентироваться. Не все нужно задачи делать сегодня, а по некоторым вообще непонятна дата исполнения. Если пользоваться только разделами, то получится некая такая мусорка. При этом часто одновременно нужны задачи из нескольких разделов (работа и встречи, например). Для себя я накрутил несколько фильтров.

• Работа на сегодня. Показывать разделы work и meeting с установленными датами Сегодня или Ранее (то есть просроченные задачи). Это самый главный фильтр, по сути, он используется 90% времени. Начинать рабочий день удобно с понимания предстоящего фронта работ. Также важно, чтобы глаза не разбегались от количества задач. Очень приятно, когда всё или почти всё сделано в конце дня, можно почесать пузико и идти обнимать жену и детей.

• Завтра. Показывать разделы work и meeting с датой выполнения Завтра. Иногда (или очень часто?) нужно понимать, что вас ждёт завтра.

• Встречи на месяц. Показывать meeting с датой на месяц вперёд. Этот фильтр я применяю не так часто, но иногда нужно посмотреть, что тебя ждёт по встречам в ближайшее время. Если вы также ведёте не только рабочие задачи, то очень удобно иногда посмотреть свысока в целом на все встречи, которые тебя ожидают. Встреча по архитектуре, ребенок в поликлинику, навестить бабулю и т.д. Здесь же можно посмотреть, нет ли случайных пересечений, не идете ли вы к зубному во время встречи с инвесторами.

Разбираем inbox

У наших задач уже есть структура, они разбиты по разделам и помечены тегами. Как дальше с этим работать, что брать в работу и когда? Что в первый раз, что при каждом очередном просмотре inbox моя логика обработки примерно такая. Каждый раз просматривая inbox, раскидываем задачи, исходя из ваших приоритетов. Что-то нужно сделать завтра, что-то через неделю, что-то записать в базу знаний, что-то удалить. При просмотре inbox также смотрю на понятность формулировки и наличие деталей к задаче, если что-то непонятно – дописываю или ставлю задачу уточнить какие-то детали.

Главное – планировать на день выполнимое количество задач. Если попробовать формализовать задачу заполнения расписания по дням, то выходит так:

• Задачи с фиксированным временем начала (в основном, это встречи/созвоны) оформляем с привязкой ко времени.

• Периодические задачи (полить цветы, актуализировать ресурсный план, подготовить отчётность, ...) оформляем как задачи, привязанные к дате.

• Теперь на завтра осталось сколько-то свободного времени, условно, 5 часов. По опыту желательно запланировать на завтра задач часа на 4, потому что неизбежно будут появляться доп задачи, которые тоже съедят время. Эти задачи я уже планирую без времени. Как только образуется свободное время, я начинаю делать очередную задачи из запланированных. Закончил всё на сегодня? Можно взять из планированных задач на завтра.

• Задачи, которые не влезли на завтра, уезжают на послезавтра, но они должны занять не больше половины доступного времени. Потом заполняется после-послезавтра и так далее. Если у вас сразу заполняется неделя вперёд, то поздравляю, вы перегружены, надо создавать своего дубля, как у Стругацких, или делегировать задачи. Почему заполняем половину? Чтобы было место для новых задач, плюс у нас будут подзадачи из декомпозированных больших задач перепланироваться. С опытом приходит понимание, сколько вы успеваете за день. И помогает в этом Ежедневный обзор, о котором пойдёт речь ниже.

Алгоритм работы с таск-менеджером

Попробуем рассмотреть мою работу на примере. Итак, начинается рабочий день.

• Включить фильтр "Работа на сегодня", то есть задачи на день. Всё просто, берем задачи и делаем. Не нужно вспоминать, чем заняться, ибо всё уже под рукой и готовое. Ключевое тут, повторюсь, в том количестве спланированных задач на день, которое реально сделать за день.

• Как только задача выполнена, делаем соответствующую отметку. Во-первых, это красиво. Во-вторых, чтобы эти задачи не мешались. Ну и в-третьих, важно видеть все выполненные задачи для мотивации.

• Если в течение дня прилетают задачи по любым каналам, то либо кладём в inbox (если задача абстрактная и непонятная), либо добавляем сразу в раздел Работа (для понятных и структурированных задач). Однако, если добавляете в "Работу на сегодня", стоит подумать, а что из запланированного у вас съедет. Время не резиновое.

• Наступает конец рабочего дня, на крайняк начало следующего. И тут обращаемся к задаче Ежедневный обзор. Что это такое? Это киллер-фича используемого мной метода ведения дел, периодическая ежедневная задача Ежедневный обзор, ниже опишу процесс работы с ней. В описании Ежедневного обзора такие чекбоксы:

  • Все ли планируемые задачи записаны? Если нет, внести в inbox.

  • Разобрать inbox. Задачи оттуда должны переехать в категорию, опционально получить тег и дату выполнения.

  • Просмотреть задачи, выполненные сегодня. Внести в список следующие шаги по этим задачам, если есть.

  • Посмотреть запланированное в "Работа на сегодня", но не выполненные задачи. Надо ли вам в связи с этим что-то делать прямо сейчас/ завтра/ на неделе/ потом? Если да, то перепланировать задачу или создать новую.

  • Есть ли в вашем списке "Работа на сегодня" старые задачи, которые менялись больше суток назад? Переформулируйте их.

По каждому пункту пройдёмся подробнее.

• Внести всё в inbox важно, чтобы разгрузить оперативную память. Какие задачи вам надо будет выполнить завтра? Подумать всё ли, что запланировал сделать, внёс в список? Просто посидеть в тишине минутку, подумать, ничего ли не упустил. Много задач на день не должно быть, и приоритизировать их после беглого взгляда очень просто. Не буду тут акцентировать внимание, как приоритизировать задачи, у вас может быть свое видение и алгоритм. Но оговорюсь, если задач на день у вас слишком много, то что-то не так в консерватории. Вы физически не сможете сделать задач больше, чем умещается в ваше рабочее время. Несделанные задачи могут превращаться в снежный ком и демотивировать. Реальность нужно принять. Задачи, которые не влезают в ваш рабочий день, нужно либо делегировать, либо удалять.

• В результате в inbox скапливается миллион всякого разного. Нужно его разгрести, сформулировать точнее, назначить категорию, тег и дату выполнения. В результате получаем пустой inbox.

• Полезно пересматривать выполненные задачи. Часто бывает так, что по результатам сделанной задачи может потребоваться новая задача. Условно, разбирали с командой беклог. После разбора нужно создать новую задачу: поставить задачи команде по результатам груминга. И вот, чтобы такое не упускать, нужен этот пункт. Просматриваем все сделанные за день задачи, и смотрим, нужно ли завести какие-то новые. Если да, то, очевидно, заводим.

• Если вы не сделали задачи, то почему? Не успели, задача непонятна, или вы чего-то ждёте? В общем, это такой пунктик рефлексии, который просит вас немного притормозить и задуматься.

• Про старые задачи. С моей точки зрения это категорически важная штука. Иногда бывает, что задачу не только за сегодня не успел, но и переносишь уже десятый раз подряд. В таком случае, стоит задуматься, почему вы её не выполняете. Достаточно частая причина заключается в том, что задача сформулирована слишком абстрактно. Вы просто не знаете, как за неё взяться и, соответственно, изо дня в день прокрастинируете и хватаете более понятные задачи. Декомпозиция задач часто может помочь. Но правда в том, что условно месяц висящая задача, которую вы тщательно переносите изо дня в день, достойна удаления. Примите, что она никогда не будет сделана, и избавьтесь от неё. Хотя, скажу честно, у меня есть пару задач, которые я переношу несколько лет, и мне уже это просто нравится :)

Пример обработки рабочей встречи. Я сам грешу бумагой, поэтому во время встреч часто записываю в блокнотик некоторые идеи и задачи. По завершении встречи я практически бездумно переношу всё в раздел inbox. Единственное, что при переносе можно указать дополнительные детали. Если среди того, что вы вносите, есть понятные задачи, с понятной датой начала исполнения, можно сразу добавить в раздел Работа с указанием даты. Напомню, что вносить стоит и совсем небольшие задачки. Например, передать Васе, что он должен завтра подготовить отчёт. Конечно, можно Васе сразу написать, но тогда вы отвлечётесь... Решать вам, мне удобнее сначала разобраться с результатами встречи.

Себе я купил TickTick premium, но, в целом, он не требуется. Подписка стоит 36$ в год, даёт календарь, хитрую статистику и разного по мелочи.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, fcron, интересных хаках вроде запуска LLM прямо в шрифте, или об архитектурных схемах. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

В одном из проектов я заметил, что выгодность для меня стала падать. Подумав, а что же такого случилось, я осознал, что за последний месяц заказчик стал проявлять особенное желание видеть меня в оффлайне, и на это (с учётом дороги, ожидания и прочего) уходило много времени. Я стал лучше готовиться к встречам, чтобы за один раз закрыть бОльшее количество вопросов, и как можно больше вопросов стараться решать в онлайне. Если бы я это не заметил, то так бы и продолжил кататься к заказчику. Выгодность проекта (в виде часовой ставки) при этом продолжила бы незаметно таять.

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

У меня в таск-менеджере есть ежемесячная задача на анализ выгодности своих проектов. Это позволяет держать руку на пульсе.

Удалённая работа

Сейчас удалёнкой никого не удивить. Но у удалённой работы есть вот какая проблема. Ты вроде дома, а вроде и на работе. Легко попасть в одну из крайностей, где ты либо избыточно много работаешь, либо, наоборот, слишком часто прерываешься в ущерб рабочим вопросам. И трекинг времени можешь помочь соблюдать work-life balance. Я заметил два момента:

— Грустный для работодателя. При работе дома можно часто отвлекаться. Полил цветы, поговорил с домашними, отвлёкся в чатик. Добавьте сюда еще проблему концентрации на сложной задаче и получится, что вроде проработал целый день, а по факту времени на работу потрачено сильно меньше необходимого. Вроде сидел целый день, а особо ничего не сделано.

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

— Грустный для меня. Просыпаюсь и сразу за работу, весь день ударно работаю. Вечером вроде уже закончил, но вот возник вопросик, и компьютер соблазнительно близко — почему бы быстро не глянуть, что там за проблема. В итоге день в работе, вечер в работе, а и вечный день сурка.

В этом случае измерение времени позволяет мне соблюдать тот самый work-life balance.

На самом деле, я часто трачу на работу больше времени, чем положено. Но важно, что я делаю это осознанно, потому что мне нравится то, чем я занимаюсь. Отслеживание времени позволяет быть в курсе ситуации и вовремя сориентироваться, если работа перестала приносить удовлетворение.

Что лучше не трекать

Небольшое предостережение. С первого взгляда может показаться: "как же классно знать, куда уходит моё время. Это же такое прекрасное поле для оптимизаций!". Но не замахивайтесь сразу на сложное — измерять всё. Сколько времени кушал, развлекался, занимался спортом, уборкой и миллионом других занятий, категории для которых часто предлагают приложения для учёта времени. Мой опыт показал, что это бесполезная информация, а отслеживание большого количества активностей требует серьёзной собранности. Без четкого понимания цели, вы, скорее всего, быстро забьёте. Если хотите попробовать трекать время, остановитесь на том, что вам действительно важно.

Что касается приложений для этих целей — я пользуюсь atracker, коллега atimelogger, но вариантов много на любой вкус.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, fcron, интересных хаках вроде запуска LLM прямо в шрифте, или об архитектурных схемах. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

– использовать лечебные капли – это уже не так тупо. Действительно, существуют капли, которые облегчают ситуацию. И наверно, если зависимость у вас не серьёзная, то они помогут, но это не мой случай. Я влип по самые помидоры.

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

– сделать операцию. Также слышал об этом, но в эту сторону пристально как-то не смотрел. Наверняка, для кого-то это окажется единственным вариантом.

Парампампам... как же в итоге все решилось у меня.

Уже и не помню, откуда мне пришла эта идея, но все оказалось очень просто. Я начал по чуть-чуть в капли подбодяжиавть простую воду (upd: в комментариях по делу рекомендуют физраствор, а не воду). Если что, крышечка капель хорошо открывается после небольшого усилия.

То есть берёте свой пузырек и подливаете туда процентов 10 воды. Когда этот пузырек закончится, в следующий пробуете добавить побольше водички. И так с каждой итерацией доля воды будет становиться всё больше. А ваша зависимость от капель всё меньше. Небольшое отступление. Некоторым снуп с водой кажется мерзким. Я разницы не чуствовал.

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

Тут-то на помощь и придут лечебные капли. Я пользовался Назонексом, но лучше проконсультируйтесь у врача. То есть в тот момент, когда увеличение дозы приводит к тому, что капли перестают работать, больше дозу воды не увеличиваем и начинаем ещё закапывать Назонекс.

В один из прекрасных дней, следуя алгоритму, я рискнул не закапывать капли на ночь. И, ГОСПОДИ, чудо случилось, я не проснулся ночью и ни разу не закапался. С этого момента я вообще перестал капать сосудосуживающие и ещё какое-то время прокапал на всякий случай лечебные.

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

Такой вот необычный для меня пост. В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, postgres_dba для анализа узких мест базы данных или fcron, интересных хаках вроде запуска LLM прямо в шрифте, или о Google design docs. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

Прелесть такого плана в том, что каждая задача мотивирует сделать следующую. Если я нашёл темы для ролика, то уже хочется написать сценарий. Когда готов сценарий, то прописать текст уже не выглядит неподъёмной задачей.

Если даже после декомпозиции я не приступаю к задаче, то тут два варианта: либо задача по факту мне не нужна и её нужно выкинуть, либо я плохо декомпозировал, и тогда надо раздробить её на ещё более мелкие подзадачи.

Для меня главный фактор откладывания задачи — её неясность. Дробление задачи позволяет неясность устранить. Задачи должны быть такого размера, чтобы минимизировать напряжение мозга: взял и сделал.

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".

Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

Я ставлю задачи:
— Выбрать сервис для замены жидкости (смотрю отзывы на картах);
— Позвонить и договориться о времени (узнать цену, сколько займёт по времени, после разговора записать адрес);
— Поехать в сервис на замену жидкости <- по факту это та же задача, но только теперь у меня нет к ней вопросов, просто беру и делаю.

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:

✅ При составлении плана учитывать будущую загрузку. Глупо планировать на воскресенье 40 задач по часу каждая, не получится столько сделать. Понимание приемлемой загрузки приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого старта я с удовольствием продолжаю делать задачу. А если нет, то не расстраиваюсь, ибо значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма . Это когда ты занят, но не тем.

А ещё я каждый день анализирую список своих задач, но это тема отдельного поста.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, postgres_dba для анализа узких мест базы данных или fcron, интересных хаках вроде запуска LLM прямо в шрифте, или о Google design docs. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео.

Кроме ютуба, для удобства есть дзен / VK / rutube.

Сегодня разберём, как корректно измерять время выполнения программы и какие причины влияют производительность. Посмотрим, как можно загрузить систему и наглядно посмотреть на её состояние.

Сравним скорость -lt и < внутри if мы в следующем видео. Начать придётся издалека, через тернии к звёздам.

Что вообще важно для любого эксперимента? Описать методику эксперимента. Для измерения скорости обратите внимание на следующие нюансы:

0. На каком оборудовании мы работаем

1. Измерять секунды и десятки секунд, а не наносекунды

2. Фиксировать условия по загрузка ядер и видеокарты, оперативной памяти, вводу/выводу

3. И сколько измерений проводить и как усреднять, средняя или медиана, что делать с выбросами и подобное

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

В начале про оборудование. Посмотрим на доступные ядра нашей системы с помощью команды lscpu. Видим 4 интелловых ядра i7-3770 с гипертредингом в 2 потока каждое, то есть 8 виртуальных ядер. Запомним - это наше оборудование

lscpu

...
CPU(s): 8

Потоков на ядро: 2

Ядер на сокет: 4

Имя модели: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

...

Для длительных временных промежутков достаточно встроенной в bash команды time:

type time

time — это ключевое слово командного процессора

Справка нас обманывает, потому что показывает информацию о бинарнике /usr/bin/time

man time

А это не то, что нужно. Это справка по такой команде:

which time

/usr/bin/time

Вот пример её вывода:

/usr/bin/time sleep 1

0.00user 0.00system 0:01.00elapsed 0%CPU (0avgtext+0avgdata 2260maxresident)k

72inputs+0outputs (1major+95minor)pagefaults 0swaps

Мне такой вывод непривычен, поэтому вернёмся к встроенному time:

time sleep 1

real 0m1,002s — общее время работы программы

user 0m0,002s — время в пользовательском режиме

sys 0m0,000s — время в режиме ядра или системных вызовов

До эры искуственного интеллекта в виде ChatGPT был популярен stackoverflow, детали смотрите там. Важно обратить внимание, что real — это про общее время работы, а user и sys — время процессорное. Для них 10 будет означать, что программа работала 10 ядросекунд — при этом неважно, 10 секунд на 1 ядро или 1 секунда на 10 ядрах

Для примера попробуем посчитать уникальные строки в большом файлике на 130 мегабайт и 14 млн уникальных строк.

time sort -u rockyou.txt | wc -l

14341564

real 0m34,771s

user 1m7,906s

sys 0m0,931s

Вот тут наглядно видно, что real — это совсем не сумма user и sys. Кстати, вам интересно, как можно изящно ускорить подсчёт уникальных строк за счёт магии баша? Их есть у меня! Лайкните этот пост, и я сниму отдельный ролик про всякие хаки и оптимизации на этом поприще.

Про встроенную команду time мы можем найти в справке по самому bash

man bash

Ищем там с помощью ввода /time (слеш, потом time), дальше сильно промотав вниз с помощью кнопки n (сокращение от next, следующий поиск). Тут и описание вывода, и переменная окружения TIMEFORMAT, с помощью которой можно настроить вывод time.

Больше о переменных окружения в нашем бесплатном курсе на степике под названием Командная строка для разработчиков – cli-for-dev.

Проще, конечно, загуглить нужное, кому нужна эта справка. Для вывода только real нам понадобится такая конструкция

TIMEFORMAT="%R"; time sleep 1

Запомнили, это пригодится позднее. Дальше о фиксированных условиях.

С этим пунктом мы надолго. Теперь посмотрим на загрузку системы и как она влияет на время работы команды. Мне нравится команда htop за наглядность. Тут показывается загрузка каждого ядра в режиме реального времени и многое другое. Строку load average мы с вами разбирали в видео про атаку forkbomb в docker-контейнере. Посмотрите, если пропустили.

Загрузим вычислитель. Нам нужно взять "тяжёлую" для процессора команду и запустить её, загрузив все логические ядра системы. Согласно философии Unix, программа должна решать одну задачу и решать её хорошо. Команда xargs умеет параллелить. Она берёт входную строку и преобразует её в одну или несколько команд. Для наглядности покажу, как xargs работает в связке с echo:

echo 123 | xargs echo my arg is

Если аргументов несколько, по умолчанию они все пойдут указанной команде:

echo 1 2 3 | xargs echo my arg is

С помощью флага -n можно настроить, сколько аргументов пойдёт в одну команду. Если указать один, то наши три числа превратятся в три разные команды:

echo 1 2 3 | xargs -n1 echo my arg is

Если указать два, то первые два аргумента пойдут в первую команду, оставшийся третий аргумент пойдёт во вторую:

echo 1 2 3 | xargs -n2 echo my arg is

Вернёмся к одному аргументу на команду. И теперь магия - укажем, что надо запускаться параллельно на всех ядрах с помощью P0

echo 1 2 3 | xargs -P0 -n1 echo my arg is

Блеск. Дело за малым - нам надо загрузить всю систему. В моем случае, как мы выяснили в lscpu, надо 8 потоков. Воспользуемся командой seq, сокращение от sequence

seq 8

seq 8 | xargs -P0 -n1 echo hello process

Чудо. Мы умеем параллельно запускать 8 команд. Теперь надо сделать так, чтобы эти команды сурово грузили процессор. Можно использовать сторонние тулзы нагрузочного тестирования типа stress, но зачем?

Есть команда yes, которая умеет адски спамить. По умолчанию она спамит буквой y, то есть всегда говорит да, прямо как Джим Керри в комедии 2008 года:

yes

Может спамить любой строкой:

yes hello world

Прикол в том, что этот спам сильно грузить процессор, что нам и нужно. Направляем вывод команды yes в чёрную дыру dev null:

yes > /dev/null

После чего смотрим в htop на загрузку. И получаем отличную жужалку, которая нагружает ядро. Но только одно. Постойте, мы же умеем параллелить!

seq 8 | xargs -P0 -n1 yes > /dev/null

Всё хорошо, но эта команда работает, пока мы её не прервём. А нам бы добавить немного удобства. Пусть система загрузится на 10 секунд. Линукс и так умеет. Команда timeout прервёт запущенную команду, если она сама не завершиться за указанное время, в моём примере 1 секунду:

timeout 1 yes

И мы ещё time можем сюда навесить. Измерим время команды yes, которую прервёт по таймауту:

time timeout 1 yes

Я вас ещё не совсем замучил? Теперь объединим всё это безобразие. На 10 секунд загрузим 8 ядер системы собранной нами на коленке жужжалкой:

seq 8 | xargs -P0 -n1 timeout 10 yes > /dev/null

В рамках нашего примера есть два сходных варианта:

seq 8 | xargs -P0 -n1 timeout 10 yes > /dev/null # Грузим sys

seq 8 | xargs -P0 -n1 timeout 10 md5sum /dev/zero # Грузим user

Теперь у нас готова жужжалка для загрузки ядра процессора. С загрузкой других компонент системы разобраться проще. Для загрузки оперативной памяти достаточно создать огромную переменную:

a=$(seq 10)

echo $a

a=$(seq 100 000 000)

Но совершенно неудобно оценивать размер. Поэтому воспользуемся питоном. Незатейливо создадим большую строку, благо звёздочка удобно переопределена для строк. Один английский символ занимает один байт плюс накладные расходы на переменную, берём их "кило", то есть 1024 и получим килобайт.

python3.10

var = "a"*10

В IDLE можно не писать print, результат работы команды выводится на экран:

var

Кстати, в питоне накладные расходы на переменную довольно велики. В случае строки это 49 байт:

import sys

var = ""

sys.getsizeof(var) # 49

var = "a"

sys.getsizeof(var) # 50

var = "a" * 100

sys.getsizeof(var) # 149

Возведём 1024 в степень. Вторая степень даст мегабайт, третья - гигабайт. То есть такая переменная займёт в памяти около гигабайта, плюс 49 байт на служебную информацию.

var = "a"*1024**3

У нас свободно около 5 гигабайт, займём их все. Пока не удалим эту переменную или не завершим интерпретатор питона, память будет загружена.

var = "a"*5*1024**3

Для просмотра загруженности подсистемы ввода-вывода есть команда iotop, которой требуются права суперпользователя. Нам нужны только первые две строки

sudo iotop

Для загрузки ввода-вывода возьмём псевдогенератор случайных чисел и будем записывать его в файл:

cat /dev/urandom > /tmp/1

Зачастую проблема не в самом вводе-выводе, а в его буферизации. Так называется отложенная запись на диск. Операционная система для более эффективной работы с оборудованием пишет не сразу. Например, после записи файла на флешку на самом деле он там окажется не сразу, а через некоторое время. Для этого существует (или существовало? кто видел флешку в 2024 году?) безопасное извлечение флешки – как раз, чтобы операционка корректно дописала отложенный буфер.

В линуксе есть команда sync, которая завершиться, когда весь буфер запишется на диск.

sync

Пробовать измерять время будем на примере цикла в баше:

i=0; while [[ $i -lt 10 ]]; do i=$(( $i+1 )); echo $i ; done; echo $i

Увеличим число нулей:

i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )); done; echo $i

Добавим time. Если просто добавить time, то мы измерим время только присваивания:

time i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )) ; done; echo $i

Чтобы измерить время всей конструкции, оформим цикл в виде отдельного процесса с помощью доллара и скобок:

time $( i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )) ; done; echo $i )

Ещё ошибка: результат подпроцесса - число, а команда time пытается это число выполнить как команду. Добавим echo:

time echo $( i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )) ; done; echo $i )

Теперь посмотрим, как на этот цикл влияет загрузку системы. Запустим монитор ресурсов htop и загрузим ядро:

seq 8 | xargs -P0 -n1 timeout 10 yes > /dev/null

Попробуем запустить наш цикл. Потом загрузим оперативную память:

python3.10

var = "a"*5*1024**3

И снова цикл. Осталось загрузить ввод-вывод:

sudo iotop

cat /dev/urandom > /tmp/1

И снова запустим цикл.

Одного измерения недостаточно. Собственно, примеры загрузки системы выше были призваны проиллюстрировать влияние внешних факторов на запуск вашего кода. Для минимизации этого влияния следует измерить несколько раз. Можно ручками внести результаты в таблицу. Но, во-первых, мы люди ленивые. А во-вторых, ручная обработка всегда чревата ошибками. Соберём всё в табличку.

А с этим есть проблема. Для вывода time в файл придётся немного извратиться. Дело в том, что перенаправление будет работать для команды выполняемой команды, то есть для всего справа от time. На помощь придёт логическое объединение в виде group command с помощью фигурных скобочек:

man bash

Ищем такую конструкцию /\{

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

TIMEFORMAT="%R"; { time $( i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )) ; done; ) ; } 2>> res.csv;

tail -f res.csv # для проверки, что пишет

libreoffice res.csv # для обработки итоговой таблицы после завершения

Если запустить libreoffice с английским языком, то запятая будет считаться разделителем разрядов и удалится, мы получим неверное время (4567 вместо 4,567).

Закроем файл и откроем снова. Переключим язык на русский, чтобы запятая стала десятичным разделителем. Впишем формулы СРЗНАЧ и СТОТКЛ.

Если запускать скрипт 10 раз лень, можно накинуть ещё цикл (больше циклов богу циклов):

for i in $( seq 2 ); do TIMEFORMAT="%R"; { time $( i=0; while [[ $i -lt 1000000 ]]; do i=$(( $i+1 )) ; done; ) ; } 2>> res.csv; done

Резюмируем. Наша методика экспериментального исследования времени работы программы выглядит так:

берём 8-ядерный i7-3770

проводим 10 измерений командой time

запускаем много циклов "-lt" vs "<"

рассчитываем среднее арифметическое и среднеквадратичное отклонение

В следующем видео заодно интереса ради посмотрим на другие языки.

Теперь вы знаете, как можно загрузить процессор, оперативную память или подсистему ввода-вывода, как посмотреть на эту загрузку и как она может влиять на программу. Такие дела.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, postgres_dba для анализа узких мест базы данных или fcron, интересных хаках вроде запуска LLM прямо в шрифте, или о Google design docs. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео.