Еще в тему – есть интересная статья, в которой автор утверждает, что создал самый быстрый вариант поиска подстроки в строке, и в доказательство приводит подробные сравнения алгоритмов.
А можно пожалуйста выложить код бенчмарков вместе с тестовым набором данных?
И с какой именно реализацией strstr проводилось сравнение? Внезапно, их тоже много.
Меня смущает два момента:
1. сигнатура не совпадает с библиотечной, т.е. для прямой замены не годится:
char *strstr(const char *s1, const char *s2)
2. понятно, что делает max_len, но непонятно, откуда взялось волшебное число 140.
Если судить по hype cycle, OpenStack приближается (но ещё не перешёл) к пику чрезмерных ожиданий. Это как подростковый секс — все говорят, но мало у кого есть. Через год-другой подождём примеров реальных внедрений, пронаблюдаем, как чувствует себя продакшен, почитаем отзывы, а там будет видно. Сейчас рано говорить о том, чем он станет.
Не то чтобы квадратично, но как full mesh… Строго говоря, n * (n — 1) / 2 и числа таки да, получаются большими.
Дело вот в чем: так ли уж обязательно общаться по принципу «все со всеми»? Не обязательно. Зависит от процессов внутри проекта, от того, насколько понятна задача и еще много от чего.
Нет, только не такое. На первый взгляд, это «джуниорский» баг, косяк и вакханалия.
И я хочу об этом поговорить (с)
Есть два варианта:
1. следовать Single responsibility principle имени Мартина (увы, его понимание у всех разное до сих пор) и возложить обязанность проверки и нормализации строки на вызывающего. Граничных случаев может быть много. Пробелы, в т.ч. два пробела подряд, знаки препинания в конце, и прочее и прочее.
2. до неприличия упороться в спорах о допущениях «что такое палиндром» и сделать функцию очень-очень умной. А потом всё равно много раз дорабатывать, потому что предположить всё невозможно. Функция из примера, допустим, уверенно считает палиндромом всякий трэш, но не считает палиндромом вот это:
console.log(isPalindrome("Аргентина манит негра"));
No valid characters to test, treated as empty string
Stack:
Error
at isPalindrome (<anonymous>:26:29)
at <anonymous>:46:13
… а чтобы понять, почему, нужно просмотреть чуть больше, чем одну строчку кода, чтобы найти причину:
// normalize string by lowercasing and removing non-word characters
stringToTest = stringToTest
.toLowerCase()
.replace(/[^a-z0–9]/ig, '');
А в будущем, в мифическом продакшене, который нагревает воздух, переворачивая палиндромы, эта функция может расрастись проверками и логированием раз в десять. Не нужно давать этому повод, я считаю :)
Чтобы обеспечить такую технологию работы, нужно убедиться, что у нас есть достаточное количество UNDO.
Рассчитывается как undo_size = undo_retention * db_block_size * undo_block_per_sec
А примерный порядок OLTP нагрузки — undo_block_per_sec — можно прикинуть так:
SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) undo_block_per_sec FROM v$undostat
Это не рядовой трейдер. Оригинал статьи про Goldman Sachs (кстати вот он) рассказывает про разработчика приложения визуализации данных. Ее зовут Самира и она на третьей сверху фотографии.
Согласен, pg_hint_plan — прикольная штука, использовал, но что удручает — это два момента:
— хинты могут использоваться только на «топовом» (внешнем) уровне запроса;
— на 9.5 работоспособность официально не подтверждена. Проверяйте, мол, сами, на свой страх и риск.
Ложка дёгтя: за 20 лет развития из коробки до сих пор нет (и мне очень этого не хватает):
1. распараллеливания одной SQL query по нескольким ядрам CPU;
2. хинтов в запросах (Oracle-like).
Человечество печет блины сколько себя помнит, а IT как отрасли от силы 70 лет.
Можно смеяться сколько угодно, но пройдёт ещё столько же времени прежде, чем IT-компании наконец научатся, как это делать.
Меня забавляет, что темы в стиле «как писать красивый код» привлекают больше внимания, нежели то, как писать фичастый код. Посмотрим правде в глаза: если у разработчика нет внутреннего чувства красоты, то его и не будет.
И с какой именно реализацией strstr проводилось сравнение? Внезапно, их тоже много.
Меня смущает два момента:
1. сигнатура не совпадает с библиотечной, т.е. для прямой замены не годится:
2. понятно, что делает max_len, но непонятно, откуда взялось волшебное число 140.
char * my_strstr(const char * str1, const char * str2,size_t slen){ unsigned char max_len = 140;Дело вот в чем: так ли уж обязательно общаться по принципу «все со всеми»? Не обязательно. Зависит от процессов внутри проекта, от того, насколько понятна задача и еще много от чего.
И я хочу об этом поговорить (с)
Есть два варианта:
1. следовать Single responsibility principle имени Мартина (увы, его понимание у всех разное до сих пор) и возложить обязанность проверки и нормализации строки на вызывающего. Граничных случаев может быть много. Пробелы, в т.ч. два пробела подряд, знаки препинания в конце, и прочее и прочее.
2. до неприличия упороться в спорах о допущениях «что такое палиндром» и сделать функцию очень-очень умной. А потом всё равно много раз дорабатывать, потому что предположить всё невозможно. Функция из примера, допустим, уверенно считает палиндромом всякий трэш, но не считает палиндромом вот это:
console.log(isPalindrome("Аргентина манит негра")); No valid characters to test, treated as empty string Stack: Error at isPalindrome (<anonymous>:26:29) at <anonymous>:46:13… а чтобы понять, почему, нужно просмотреть чуть больше, чем одну строчку кода, чтобы найти причину:
// normalize string by lowercasing and removing non-word characters stringToTest = stringToTest .toLowerCase() .replace(/[^a-z0–9]/ig, '');А в будущем, в мифическом продакшене, который нагревает воздух, переворачивая палиндромы, эта функция может расрастись проверками и логированием раз в десять. Не нужно давать этому повод, я считаю :)
Чтобы обеспечить такую технологию работы, нужно убедиться, что у нас есть достаточное количество UNDO.
Рассчитывается как undo_size = undo_retention * db_block_size * undo_block_per_sec
А примерный порядок OLTP нагрузки — undo_block_per_sec — можно прикинуть так:
SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) undo_block_per_sec FROM v$undostat
1. https://habrahabr.ru/post/203320/
2. https://habrahabr.ru/post/203386/
3. https://habrahabr.ru/post/203484/
— хинты могут использоваться только на «топовом» (внешнем) уровне запроса;
— на 9.5 работоспособность официально не подтверждена. Проверяйте, мол, сами, на свой страх и риск.
1. распараллеливания одной SQL query по нескольким ядрам CPU;
2. хинтов в запросах (Oracle-like).
Я уверен, повара точно знают, как печь блины.
А айтишники (в широком смысле) — не всегда знают, как делать IT.
Собственно, в этом вся изюминка ситуации.
Можно смеяться сколько угодно, но пройдёт ещё столько же времени прежде, чем IT-компании наконец научатся, как это делать.