додав в linkedin

А, ось що малось на увазі. Node.js не для CPU intensive операцій, а для I/O intensive. Якщо написаний неоптимальний алгоритм, то він якраз і спричиняє ці CPU intensive операції, та призводить до блокування обробки наступних запитів. На початку статті якраз і описаний такий CPU intensive алгоритм, який займає на виконання одного запиту 174 мілісекунди. В кінці ж статті час виконання запиту лише 2 мілісекунди.

розрахунки в Event loop свідчать про помилку

Вони свідчать про милку, якщо вони CPU intensive. Якщо ваш API робить прості перетворення, або певну агрегацію даних — це також розрахунки. І це повністю ок, якщо він робить їх швидко. Не всі розрахунки однакові.

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

А потім на співбесіду оцінюєте

відповідь є правильною, але неповною

Тобто, якщо людина каже правильну відповідь, але можливо не каже якусь деталь, то ви таку відповідь зараховуєте, як неправильну? Ви не задаєте уточнюючі питання? Людина банально може просто забути про якусь деталь згадарти, а ви вже ставите їй мінус, замість того, щоб уточнити.

Поясніть, що мається на увазі, будь ласка.

Тезис говорить про те, що кандитат принаймі розглядає можливість покращення продуктивності програми через використання інших алгоритмів. Це є дуже важливим, оскільки він піддає критиці програмкий код, а не каже відразу, що хочете більше продуктивності, ставте більше оперативки, або додавайте більше віртуалок.
Якщо бути точним, я використовую «оптимальніших», а не «оптимальних».

оптимальніших алгоритмів

Якщо ви покращуєте алгоритм (робите його оптимальнішим), то ви вже працюєте в якомусь заданому контексті.
Думаю в гуглі, фейсбуку і решті від вас очікують, що ви самі запитаєте про контекст алгоритму, або скажете, як цей алгоритм буде поводитися в різних контекстах. Цікава ж не лише глибина знання, але і ширина.

Це насправді значно більше каже про кандидата, ніж коли задаєш точкові питання. Наприклад, мене цікавить CAP теорема і які наслідки з неї випливають. Нехай ми спілкуємось в контексті онлайн магазину. Замість того, щоб прямо запитати про CAP теорему, я скажу щось таке «а якщо тепер бізнес розширюється і вам потрібно розподілити вашу систему між декількома континентами на планеті, з якими проблемами ви зіткнетеся?» Якщо він сам задетектить, що потрібно буде пожертвувати або Availability, або Consistency, або шукати якийсь між ними баланс, то це в рази краще, ніж він просто дасть мені визначення теореми, чи розкаже наслідки. А ще, якщо він запитає, чи залишиться один склад, чи будуть окремі склади для кожного регіону, це взагалі круто, бо він скоріш за все розуміє, що таке Data Sharding. Це говорить про те, що такі речі він приймає до уваги, коли розробляє рішення, а не просто знає, що таке десь є. Або, наприклад, мене цікавлять SQL Isolation levels. Замість того, щоб попросити перерахувати рівні, я запитаю щось таке: «Якщо мені потрібно максимально швидко дізнатися, скільки приблизно кожного виду товарів залишилось, як це зробити?» Те, що він почує «приблизно і максимально швидко», і зробить висновок «ага, значить транзакції можна читати незакоміченими» скаже значно більше, ніж якщо він знає про рівні ізоляції, але навіть не припускає, що можна використовувати щось інше, ніж Read Commited. Я можу продовжити історію і запитати, а якщо мені такі дані потрібно дуже часто. І ми переключаємось на кеші. І так далі.

Так, ви праві — в JS справжнього масиву немає.

Те, що JavaScript називають масивом (array), насправді є списком (list), оскільки його довжина може змінюватися.

А HashMap — це звичайний об’єкт, або Map. Map оптимізованіший для частих вставок та видалень. А ще, в Map ключами можуть бути не тільки стрічки.

Есть еще interpolation search, его сложность в лучшем случае O(log(log(N)),

Не чув про нього, обов’язково пререгляну. Дякую!

Ничего подобного, позиция в массиве это «hash(key) % length» где длинна массива как правило простое число. При определенном количестве добавленых в хеш элементов происходит перестройка этого массива в новый с большим размером.

Я бачив в літературі обидва випадки. Так як в лекціях, на які я посилаюсь, вказаний варіант з генеруванням хеша меншого довжині масиву, я вказав цей варіант.

www.cs.princeton.edu/...​lectures/34HashTables.pdf
Designing a hash function
Required properties. [for correctness]
・Deterministic.
・Each key hashes to a table index between 0 and m — 1.

Абсолютно лишнее условие для работы хеш-колекций. Это важно только в криптографии, где тоже используются хеш-функции.

Для хеш-колекції — так, зайве. Тим не менше, це важлива ознака хеш-функцій, тому варто про неї згадати. Багато хто знає, що паролі в базі даних хешуються. І як ви вже згадали, тут ця властивість — важлива.

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

Так в цьому була і суть статті: розказати, як вони всередині працюють )).

Як прискорити код з 15 до 1000 запитів за секунду

Продуктивність — це скільки одиниць система може обробити за певний проміжок часу.

Було 15 за одиницю часу, а стало 1000. Код став продуктивніший. Так він став ефективніший, бо використовує менше процесорних ресурсів для обробки одного запиту, але «було 15 стало 1000» говорить прямо про продуктивність і непрямо про ефективність. Саме про продуктивність прямо сказано у заголовку цієї статті.

продуктивність по визначенняю це єфективне використання ресурсів. www.google.com/...​&sourceid=chrome&ie=UTF-8
А маштабування і т.д. просто додають додаткові ресурси а не дозволяють використати ефективніше вже існуючі

Ні, це визначення є не вірним. Не можна ототожнювати «продуктивний» і «той, що ефективно використовує ресурси». Продуктивність може бути досягнута і неефективним використанням ресурсів. Завод може підвищити свою продуктивність (випускати більше товарів в місяць) тим, що робітники будуть працювати у 2 зміни, а може роботизувати процес виробництва. Ви ж не скажете, що подвійна робоча зміна — це ефективно? Тим не менше, раз завод витустить в місяць більше товарів, він працював продуктивніше, ніж попередній місяць. Як я вже писав і ви з цим погодилися «продуктивність — кількісна характеристика, а ефективність — якісна».
Те ж саме з автоматизованими системами: мені потрібно більше запитів в секунду (більше продуктивності), я ставлю або більше віртуалок (не дуже ефективно), або покращую алгоритми (більш ефективно), якщо це можливо. І збільшення кількості віртуалок, і покращення алгоритмів впливають на продуктивність системи, але покращення алгоритмів не вимагає додаткових процесорних ресурсів, що є більш ефективно.
Переходимо по вашому ж посиланню (продуктивність визначення). Перші посилення реферат і вікіпедія — скіпаємо. Далі
bakertilly.ua/news/id46342 Продуктивність і ефективність: в чому різниця?
Вже ніби як наштовхує на думку, що ці поняття не тотожні.
«Хоча продуктивність і ефективність іноді сприймаються як синоніми, насправді мають два різні значення. Ці поняття переплетені, але між ними є важлива відмінність, яка значно впливає на те, як виконується робота.»
«Словникове визначення продуктивності таке: ефективність продуктивних зусиль, особливо в промисловості, вимірюється в одиницях продуктивності. Іншими словами, якщо ви видали 1 000 одиниць за тиждень і 1 100 одиниць на наступному, то другий тиждень був продуктивнішим.»
«Ефективність же полягає в тому, щоб працювати розумніше, а не старанніше. Якщо ви працюватимете більш організовано і компетентно, то зможете виконати завдання швидше, ніж зазвичай. Наприклад, якщо можете написати пост на 600 слів за 30 хвилин замість 40, ви підвищите свою ефективність.»
Отже, продуктивність — фіксований час, але кількість вироблених одиниць за цей час різна. Ефективнісь — кількість вироблених одиниць фіксована, а час різний.
Повертаємось до заголовку «15 за секунду і 1000 за секунду» — що з цього фіксоване, одна секунда, чи 15 і 1000? Про що стаття: про продуктивність (фіксований час, одна секунда), чи ефективнісь? Якби ця стаття була про ефективність, то загаловок був би «Як прискорити код опрацювання 1000 запитів з 10 хвилин до 1 секунди».
Ну і твердження «Performance і Productivity перекладаються однаково на українську, як Продуктивність». Тобто вигадати нове слово в українській мові, яке буде означати Performance, але не буде означати Productivity? Я б розумів, якщо стаття була на англійській і ви б сказали, що я замість Productivity, я вживаю Performance. Але в українській мові є одне слово — Продуктивнісь. Якби було ще якесь, то ви б його назвали, а не говорили відповідники з англійської.

Ага, дуже важливо прогнозувати кости наперед. Всі клауди дуже дешеві на старті. Потім коли починається лоад, вже все не так райдужно. Якщо лоад постійний, то AWS лямбди можуть стати золоті. Чув про стартапи, де лямбди були у 8 раз дорожчі, ніж аналогічні по лоаду EC2.

У каждого прохода естимейт в 150 тыс лет.

епічно ))))

Так, хороша ідея

я —

Продуктивність — це скільки одиниць система може обробити за певний проміжок часу.

ви —

це визначення performance

ви —

чого це маштабування, кеші і т.д. стали засобами підвищення продуктивност

тому що вони дозволяють обробляти більше запитів за певний проміжок часу. Я весь час говорив про performance, український переклад — продуктивність.

На співбесіді я розпитую про предменту область одного з проектів кандидата. Тоді починаю розпитувати про проблеми, або складні задачі, які там були. Співбесіда — досить стресова подія. Краще говорити про ті речі, з якими кандидат добре знайомий і де почуває себе комфортно. Тоді, коли ми зробили певний контекст, я починаю запитувати гіпотетичні задачі в цьому контексті. Ну і тут не так важливий розв’язок, як те, що кандидат бере до уваги, які доповнюючі питання ставить, як побудований його процес прийняння рішень, чим він керується, як він робить оцінку своїх рішень і так далі. Якщо мене цікавить щось конкретне, я можу задати йому певні константи і спостерігати, як він змінює своє рішення.

Ну але я і не хотів сказати Productivity. Я хотів сказати Performance. Гугл як і я прекладає Performance як Продуктивність. translate.google.com.ua/...​k&text=system performance

У мене були думки використати якісь задачі, наближені до роботи в реальному часі. Наприклад фінансові біржі, онлайн ігри, computer vision. Там багато даних і вони кожного моменту змінюються. Але я зупинився на прикладі з погодою, бо його дуже легко зрозуміти і сам алгоритм також простий. Це не була стаття «Ось як треба опрацьовувати дані про погоду за рік», це стаття скоріше про «Давайте оптимізуємо алгоритм задачі, яка повторюється 1000 разів в секунди»

Ну от візьмемо коментар Roman Pavlyuk вище. Був собі сініор. Написав програму з кубічною складністю. Прийшли 1,000 елементів, які оброблялися за 1,000,000,000 кроків, і програма відвалилася за 30 хвилин. Хіба таке не може трапитися кожного дня?) Багато проектів пишуть код і не підозрюють про наслідки до першого, навіть не дуже великого, навантаження.

Запит в БД також потрібно ефективно написати. Або зробити Stored Procedure, яка теж має бути ефективно написана. Це як закон збереження енергії, лоад сам по собі нікуди не дінеться, ви просто перенесете його з API на БД. В свою чергу ресурси БД також обмежені. Якщо ви маштабуєте stateless API, ви просто додаєте нові ноди після лоад балансера. БД вже не так легко маштабується, бо вам потрібно думати про цілісність даних.

Продуктівність — це скільки одиниць система може обробити за певний проміжок часу. Це кількісна характеристита. Єфективність — це вже якісна, тобто на скільки ефективно в порівнянні з іншою системою вона використовує ресурси. Якщо є два автомобілі і вони можуть на одному баку проїхати 1000 кіломентів, то їх продуктивність однакова. Але якщо один з них потратить на 20% менше пального, то він ефективніший. Якщо одна система за хвилину може обробити 10,000 запитів, а інша тільки 9,000, то перша продуктивніша, ніж друга. Але якщо друга система потребує один сервер, щоб обробити 9,000 запитів, а перша 2 таких самих серверів, щоб обробити 10,000, то друга ефективніша.