Преди известно време бях на пробен изпит за едно от моите интервюта, което в крайна сметка получих работата.

Получаването на тази работа е дълга история, така че няма да ви занимавам с това.

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

След около 4 минути го завърших и той премина всички тестови сценарии и ме направи много горд, продължавам с други тестове, които ми хрумнаха, какво ще стане, ако и те се интересуват от ефективността на метода?, така че започнах да го рефакторирам и да го стартирам срещу тестовите сценарии и отново заработих като чар.

Поради ограничението ми във времето в крайна сметка продължих напред и завърших останалите тестове. завърших ги малко след това и изпратих отговорите си.

Но едно нещо продължаваше да пее в ъгъла на ухото ми, че ами ако while(true) беше по-бързо и те можеха да приемат това като отрицателна точка?

Структурата на интервютата е планирана по такъв начин, че правя тези тестове и те ще ме предизвикат в следващото интервю.

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

За всеки показател трябва да вземем под внимание хипофиза, сценарии, които ще тестваме един срещу друг и разбира се метрики(известни още като резултати ).

Хипофиза:

While(true) се представя по-добре от for(;;) при изпълнение на следния метод:

Сценарии:

#1: Стартирайте метода add с помощта на for(;;) и върнете времето за изпълнение.

#2: Стартирайте метода add с помощта на while(true) и върнете времето за изпълнение.

И двата сценария по-горе се изпълняват спрямо времето, което означава, че се опитваме да изчислим колко време е необходимо за изпълнение на метода add() за определен брой пъти, което в този случай беше 1 милиард пъти( цикли).

Показатели (резултати):

Струва си да се отбележи, че моят бенчмаркинг стигна до изпълнение на сценария 100 пъти и изчисляване на средната стойност, сумата и мин. (което показва, че най-бързият резултат във всеки сценарий) на резултатите.

След като изпълних бенчмарка на моя лаптоп, който е Macbook air 13-инчов, 2017 г., с 1,8 GHz двуядрен процесор Intel Core i5 и 8 GB DDR3–1600 RAM и ~250 GB флаш памет,

С гордост заключих, че for(;;) е по-бърз от while(true) въз основа на следните резултати.

За разбивка на резултатите, средно, for(;;) изчислява всичко за ~725,90 msв сравнение с~804,94 ms за while(true) което заключава, че кой е по-бърз.

За min, което изчислява най-бързото време през всеки опит, отново for(;;) дойде по-бързо с ~703,79ms в сравнение с ~ 704,17 ms.

Общо for(;;) отново беше по-бързо, като изпълни всичко за ~75 290,15 мсек (~75,2 сек) в сравнение с ~80494,78 мс (~80,4 сек) , което отбеляза резултат за сценария while(true)на.

Ясно е, че for(;;) е по-бързо от while(true).

Можете дори да проверите това, като поставите данните в графика.

PS: Ако се чудите защо диаграмата има много пикове, това е заради Събирането на боклука. след като nodejs работи, ще има период от време, в който целият процес ще замръзне, докато GC не изчисти паметта и след това преведе процеса в състояние на изпълнение. този процес се изпълнява на интервални бази, които можете също да манипулирате, като използвате атрибута— gc-interval на командата node.

Този атрибут ще включва двигател V8. можете да използвате командата node — v8-optionsза да видите опциите на V8. повярвайте ми, след като го разгледате, там ще намерите много интересни неща, които да ви занимават.

Но изчакайте малко, току-що проведох тестовете и виждам различни резултати.

Изглежда, че грешах и докато е по-бързо.

но как изобщо е възможно това?

Повярвайте ми, когато казвам, преглеждах кодовете си толкова много пъти, за да открия проблема, но не можах да го намеря.

На този етап заключих, че резултатите не са убедителни и следователно ненадеждни.

Това е мястото, където някак се разочаровах и спрях да работя по него.

Вземете втори шанс:

Отне известно време и някак забравих за този мой малък проект, че случайно отворих един от препоръчаните видеоклипове в youtube, свързани с обратно инженерство и работа с инструменти като IDA и достъп до вградени системи от UART.

Когато погледнах анализа на IDA за фърмуера на устройството, до което човекът от YouTube получи достъп чрез UART,сигнах, че байт кодът може да е ключ към бенчмаркинг и да видя кой е по-бърз веднъж завинаги.

Така че започнах да копая.

Спомняте ли си преди малко споменах за опциите V8 на nodejs? беше полезно, когато пуснах grep на байт код на ключова дума и получих това:

Както казват французите, et voila !!!

Сега всичко, което трябваше да направя, беше да пренапиша някои неща и да продължа да извличам байт кода на моята сценарна функция:

Сега това, от което се нуждая, е да извлека байт кода, генериран от интерпретатора на запалване за testFor()и testWhile() и да сравня резултатите:

Шокиращо, освен адресите на паметта, инструкциите са едни и същи.

Заключение:

Както заключиха резултатите, при изпълнението няма разлика между използването на for(;;) и while(;;).

Трябва обаче също така да спомена, че този тест се проведе при определени условия, които изиграха ролята за получаване на този резултат, като архитектура на процесора (x86 известен още като CISC), която може да се окаже неблагоприятна за своите съперници като RISC, който е изобретен за вградени чипове от arm, съперници на двигателя на javascript като SpiderMonkey, JavaScriptCore, Chakra или двигателя на facebook hermes.

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

Пуснах моите експерименти по тази тема в Github.

Искате ли да се свържете?

Винаги можете да се свържете с мен на Twitter по всяко време и аз ще се върна при вас възможно най-скоро.

Винаги съм готов да експериментирам повече и да правя проучвания, свързани с данни, така че пишете ми, ако имате забавни идеи