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

PD>Лепить в одну строку, может, и не стоило бы, хотя ИМХО от разбития этой строки на части мало что бы изменилось.
Понятность кода бы улучшилась.

PD>Возьми любую реализацию серьезного математического алгоритма. Код, конечно, понятный, если это хорошая реализация, но обеспечить понятность кода — это не самая главная задача для автора.
Что именно в этой строке такое важное для производительности что нельзя было написать в более понятном виде?

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

SA>Бугага. А Вы точно понимаете, что именно там написано?
я точно понимаю что там написано. что не так?

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

CC>Что именно в этой строке такое важное для производительности что нельзя было написать в более понятном виде?

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

Здравствуйте, Умака Кумакаки, Вы писали:

УК>из функционального стиля
Аааа, так вот как называется этот, гм... стиль

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

CC>Аааа, так вот как называется этот, гм... стиль

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

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

PD>>Лепить в одну строку, может, и не стоило бы, хотя ИМХО от разбития этой строки на части мало что бы изменилось.
CC>Понятность кода бы улучшилась.

PD>>Возьми любую реализацию серьезного математического алгоритма. Код, конечно, понятный, если это хорошая реализация, но обеспечить понятность кода — это не самая главная задача для автора.
CC>Что именно в этой строке такое важное для производительности что нельзя было написать в более понятном виде?

Не получилось, видимо, у меня объяснить. Попробую еще раз.

Дело не в том, что его нельзя было бы улучшить, и не в том, что можно было написать в более понятном виде. Можно, конечно.

Дело в акцентах, в тех приоритетах, которые важны при той или иной разработке.

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

В разработках бизнес-приложений важнейший акцент — сопровождаемость и возможное модифицирование кода. И это при том, что сам по себе код состоит из ряда более или менее понятых действий и его надо написать, в общем-то, зная, как это делать.

А есть разработки, в которых основная проблема — не сопровождение и не модифицирование, а то, как вообще сделать. Потому что именно это и непонятно на начальном этапе разработки. И основная головная боль — найти подходящий алгоритм, который дает нужные результаты, ну и скорость может оказаться не последним делом.
И если на этом этапе ко мне придут и скажут, что у меня не в порядке отступы и табы, длинные строки и т.п. — я их и слушать не буду, более того, буду, наверное, довольно резок. Мне просто не до этого, у меня совсем другие проблемы. Мне задачу бы решить, а никак не получается, проблем выше крыши, а Вы мне про табы и длинные строки!

Нужно ли потом отрефакторить и привести к более читаемому виду? It depends. Зависит от того, что с этим кодом потом будут делать. Вполне возможно (и похоже, что так и было в случае ТС), что автор вообще не предполагал возможной модификации этого кода кем бы то ни было, кроме самим собой. Это может показаться странным, но такое бывает, и в таком проекте я участвовал. Единственное требование, которое мне было в нем поставлено — максимальная производительность. Ради этого разрешались любые отступления от любых канонов. А модифицировать этот код предстояло мне самому, до тех пор, пока он вообще не будет выброшен и заменен новым. Скажешь — такое не бывает ? Бывает

В общем, есть задачи и задачи, и приоритеты бывают разные.

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


Источник внизу.

  uint32 cur_hashnr;
  const uchar *cur_key;
  size_t cur_keylen;
  LF_SLIST *link;

retry:
  cursor->prev = head;
  do /* PTR() isn't necessary below, head is a dummy node */
  {
    cursor->curr = (LF_SLIST *)(*cursor->prev);
    lf_pin(pins, 1, cursor->curr);
  } while (*cursor->prev != cursor->curr && LF_BACKOFF);
  for (;;) {
    if (unlikely(!cursor->curr)) {
      return 0; /* end of the list */
    }
    do {
      /* QQ: XXX or goto retry ? */
      link = cursor->curr->link.load();
      cursor->next = PTR(link);
      lf_pin(pins, 0, cursor->next);
    } while (link != cursor->curr->link && LF_BACKOFF);
    cur_hashnr = cursor->curr->hashnr;
    cur_key = cursor->curr->key;
    cur_keylen = cursor->curr->keylen;
    if (*cursor->prev != cursor->curr) {
      (void)LF_BACKOFF;
      goto retry;
    }

Ну и как ?

Источник — файл mf_keycaches.cc из исходников MySQL сервера.

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

PD>Ну и как ?

Кусок старого говна которое к счастью работает и трогать не надо.

PD>Источник — файл mf_keycaches.cc из исходников MySQL сервера.

Посмотри как может и должен выглядеть код в 202х годах https://github.com/cockroachdb/cockroach/blob/master/pkg/keys/keys.go

Особо советую обратить внимание на комментарии и обработку ошибок.

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

KP>Кусок старого говна которое к счастью работает и трогать не надо.

К счастью работает — это неинтересно. Неработающий код в SQL сервере — не было бы сервера

А вот почему не надо — можно поподробнее ? Почему его не отрефакторить как следует ? Чтобы понятно было

Почему Oracle это не делает ?

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

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

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

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

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

PD>Ну и как ?

Редкостное Г. Неинициализированные переменные, явная потребность вынести содержимое do-while в отдельные функции, непонятно что спрятано за LF_BACKOFF, навороченное сочетание бесконечного цикла+переходы по goto+преждевременный возврат через return. Говнокод как он есть.

Да, в старых и давно работающих продуктов такого навалом. Хорошего в этом только ничего нет.

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

PD>А вот почему не надо — можно поподробнее ? Почему его не отрефакторить как следует ? Чтобы понятно было

Почему не надо трогать? Потому что а) оно или работает или все знают стандартный обходной путь, б) это говно может совершенно непредсказуемо себя вести и угадать что сломает малейшее изменение сложно, в) не факт что такое чудовище корректно покрыто тестами, т.к. оно скорее всего меняет внешние состояния (тот же lf_pin).

PD>Почему Oracle это не делает ?

Потому что оно приносит деньги сейчас. То что его нельзя менять и развивать... это не такая большая проблема пока платят. Не так давно была забавная история о том, как одно небольшое изменение в оракловой базе легко занимает квартал с объяснением почему.

Кстати, про:

PD>И если на этом этапе ко мне придут и скажут, что у меня не в порядке отступы и табы, длинные строки и т.п. — я их и слушать не буду, более того, буду, наверное, довольно резок. Мне просто не до этого, у меня совсем другие проблемы. Мне задачу бы решить, а никак не получается, проблем выше крыши, а Вы мне про табы и длинные строки!

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

KP>Посмотри как может и должен выглядеть код в 202х годах https://github.com/cockroachdb/cockroach/blob/master/pkg/keys/keys.go

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

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

В>Это тот самый таракан, который отваливается регулярно по тыщще разных причин? И где вставил-получил данные вполне может привести к тому, что данных ещё нет-)))
В>?

Говнокод решает проблемы согласованности данных. Ай молодца, вот это я понимаю инженерный образ мысли!

KP>Говнокод решает проблемы согласованности данных. Ай молодца, вот это я понимаю инженерный образ мысли!

Это где я это писал?

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

S>А тут не нужно думать. Еще на стадии обучения программированию на подкорке должно были быть выбиты навыки выбора внятных идентификаторов и аккуратного написания кода.

На стадии обучения программированию любое имя переменной не могло иметь больше 6 символов и GOTO был в каждой десятой строчке . Потому что писал я тогда на Фортран-4.

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

PD>>А вот почему не надо — можно поподробнее ? Почему его не отрефакторить как следует ? Чтобы понятно было

KP>Почему не надо трогать? Потому что а) оно или работает или все знают стандартный обходной путь, б) это говно может совершенно непредсказуемо себя вести и угадать что сломает малейшее изменение сложно, в) не факт что такое чудовище корректно покрыто тестами, т.к. оно скорее всего меняет внешние состояния (тот же lf_pin).

Совершенно верно. И по коду ТС то же самое.

PD>>Почему Oracle это не делает ?

KP>Потому что оно приносит деньги сейчас. То что его нельзя менять и развивать

Ну как сказать... Меняют, и порой не в лучшую строну. Правда, насчет ядра сервера я не в курсе, а вот в Java драйвере при переходе от 5.x к 8.x сделали ошибку при работе с датой. Я им даже баг-репорт на эту тему написал, ошибку признали и написали — мы решили переписать этот код. На мой наивный вопрос, нельзя ли этот фрагмент взять из старого кода, ответ был — ничего оттуда взять нельзя, там все настолько запутано, что никак не взять


PD>>И если на этом этапе ко мне придут и скажут, что у меня не в порядке отступы и табы, длинные строки и т.п. — я их и слушать не буду, более того, буду, наверное, довольно резок. Мне просто не до этого, у меня совсем другие проблемы. Мне задачу бы решить, а никак не получается, проблем выше крыши, а Вы мне про табы и длинные строки!

KP>В компании с современными процессами, такой код нельзя даже банально собрать на сборочном конвеере. CI его забракует еще до того как попытается собрать.

Какой там CI, какой там сборочный конвейер, какие там процессы! Я алгоритм придумать не могу, бьюсь над ним уже бог знает сколько времени, а результаты неудовлетворительные. А ты мне про CI.

Никак ты понять не хочешь, что бывают разные задачи.

Кстати, а как насчет этого кода MySQL ? В Oracle есть этот CI ? И как он его пропускает ?

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

PD>Какой там CI, какой там сборочный конвейер, какие там процессы! Я алгоритм придумать не могу, бьюсь над ним уже бог знает сколько времени, а результаты неудовлетворительные. А ты мне про CI.

Я попробую упростить мысль. Исследовательскому коду "я алгоритм придумать не могу" не место в продукте. Автор поста обсуждает именно продуктовый код, пример из MySQL тоже продуктовый код. Ни в первом, ни во втором месте такого быть не должно. При этом у MySQL есть довольно веское оправдание для этого безобразия — в то время когда код был написан, такой код не считался говнокодом, т.к. инженерные практики еще толком не сложились. Писать сейчас так же — вот это уже плохой знак.

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

KP>При этом у MySQL есть довольно веское оправдание для этого безобразия — в то время когда код был написан, такой код не считался говнокодом, т.к. инженерные практики еще толком не сложились.

Да ладно. Конечно, в 1995-ом не было TDD, юнит-тестов и CI, но такой код уже тогда считался говном.

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

KP>Я попробую упростить мысль. Исследовательскому коду "я алгоритм придумать не могу" не место в продукте. Автор поста обсуждает именно продуктовый код, пример из MySQL тоже продуктовый код. Ни в первом, ни во втором месте такого быть не должно. При этом у MySQL есть довольно веское оправдание для этого безобразия — в то время когда код был написан, такой код не считался говнокодом, т.к. инженерные практики еще толком не сложились. Писать сейчас так же — вот это уже плохой знак.

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

Ладно. Чтобы было понятнее, расскажу про задачу.

Есть фотографии конвертов. На конверте клеточки, а в них рукой написан числовой индекс. Этот индекс потом будет опознаваться соответствующим engine, это не моя проблема. Конверты не российские, стилизованных цифр там нет, пишут просто от руки.
Проблема в том, что эти клеточки мешают распознаванию.
Задача — клеточки убрать. Текст в клеточках не трогать. Все. Вся задача.
Ну казалось бы просто — найти линии и их удалить.
Если бы так...
Во-первых, пишут бог знает как и порой цифры пересекают линию. Начинаешь удалять линию — портишь цифры.
Во-вторых, сканер не всегда эти клеточки точно сканирует. Иногда от них только кусочки линий остаются, остального нет.
В третьих, хотя все эти линии должны быть горизонтальными или вертикальными, в реальности все это далеко не так. Не совсем аккуратно лег конверт — получите 10-15 градусов уклон.
В четверых, толщина линий различна, и на разных картинках, а порой и на одной.
В пятых, мусор тоже есть. Какие-то посторонние точки и линии, бог его знает, откуда они.

CI нет. Конвейера тоже нет. Тестов искусственных тоже нет.
Что есть — фотографии, несколько сот штук. Все.
Оценка будет производиться так. Запустят они мой код на всех этих картинках, потом визуально посмотрят, что получилось и скажут — вот тут хорошо, а вот тут нет, цифру испортил, не опознают потом ее.
Начинаю править код, чтобы цифры не портить — линии остаются.
Вот так и работал. Экспериментировал с поиском линий, с удалением мусора, подбирал параметры для известных алгоритмов, конструировал свой собственный для данного конкретного случая.

Надеяться тут на 100% успех — невозможно. А пока что то, что есть, надо отправлять в production, а мне улучшать дальше.