Да там нету как таковых исходников. Я сначала хотел все по правильному сделать, для каждого теста свою функцию и ее вызывать в цикле, но после того как увидел, сколько функция сама по себе выполняется…
В итоге пришлось для каждого нового теста комментить старый код внутри тела цикла и писать новый.
Там все просто было, брался шаг цикла (от нуля до миллиона соответственно) и делился с остатком на число ветвей (a=i%8, где a — условие ветви, i — шаг цикла, 8 — кол-во ветвей).
Таким образом можно получить равномерное распределение по всем ветвям.
Соответственно, в каждом из тестов и на каждом прогоне ветви вызывались в одном и том же порядке и пропорциях.
Я там еще правильно сказал — зачем делать медленно, если можно делать быстро с теми же трудозатратами?
Вот вам если ДедМороз предложит совершенно бесплатно взять 10 000 рублей или 9 960, на выбор — вы что возьмете? Разница то вроде невелика.
Данное действие повторялось несколько раз в каждом браузере, дабы выявить некий средний результат (он обычно колеблется в пределах +-2-5% в зависимости от текущей загрузки системы). Средний результат (в миллисекундах) записывался в таблицу.
Под заголовком методология написано.
Ну во первых, тысячи вызовов запросто могут быть. Иногда даже не замечаешь, как в одном методе вызывается другой, в нем третий, там еще обертка. В итоге вроде вызываешь метод 200 раз, а на самом деле тысяча-другая функций вызывается в это время.
Во-вторых, непонятно, что значит экономия на спичках.
Вот конкретно пара примеров — есть прямой цикл, есть обратный. Обратный в 2-3 раза быстрее. Да, разница в абсолютном показателе невысока, но зачем делать медленно если можно сделать быстро (при условии что порядок перебора не важен)? Инвертированный цикл даже короче в записи.
Еще пример — приватные и обычные свойства объекта. Некоторые любят понаделать приватных свойств, понаписать к нем геттеров (как привыкли в других языках), и потом копеечка к копеечке интерфейс может начать тормозить. Тесты наглядно показывают, чем это может грозить.
Ну оно вроде как друг с другом связано )
Логика то в конечном итоге через конструкции и выражается.
Кроме того, некоторые решения могут быть очень логичными и правильными с точки зрения архитектуры, но не оптимальными с точки зрения производительности в конкретном узком месте. Тут уже как обычно надо искать «золотую середину».
Прям получается схема клиент-сервер, причем клиент ну очень тонкий )
По моему опыту, нормальный менеджер проекта (что во фрилансе, что в студиях) берет на себя 90% геморроя, связанного с работой с клиентом, согласованием и написанием ТЗ, «утрясанием» всех вопросов, а также, что немаловажно, своевременным «выбиванием» денег.
И я с радостью готов отдать ему до 50% стоимости сайта за это, вместо того чтобы решать такие вопросы самому. Каждый должен делать то что у него лучше получается.
Схема, описанная в статье, уж больно ломкая, и в первую очередь из-за человеческого фактора. И по-моему, помимо всех прочих причин самая неприятная — как только такой менеджер начнет что-нибудь из себя представлять, т.е. реально разбираться в сфере создания сайтов и работе с клиентами, ему прямая дорога в руководители собственной региональной студии. Иначе кроме как дураком его назвать будет нельзя.
Т.е. Undefined, Null, Boolean, Number, String — это все примитивные типы, а Object — единственный не примитивный тип, от которого производными являются всякие Array, Function, RegExp и т.д.?
Если бы я хотел сказать, что это свойство порожденного объекта, то я бы сказал «у объекта есть собственное свойство constructor». Поскольку в данном контексте нам важно лишь то, что в этом свойстве лежит, то не не имеет значения, находится оно фактически в объекте или его прототипе — главное что оно доступно для чтения.
Вообще, видимо, это все вопрос терминологии и «разжевывания объяснений» )
Тут дело даже не в обертке.
Конструктор то все равно ручками пишем. Вот и спрашивается, чем B.parent.apply(this, arguments) лучше по сравнению с this.init_A(arguments);
Делегирующее — это общая характеристика наследования в JavaScript. Я пытался подобрать термин именно для обозначения того, что образуется иерархическое наследование, когда прототип имеет собственный прототип и так далее. Видимо, термин подобрал неудачно. Лучше, пожалуй, эту часть фразы убрать вообще.
> Используя эту терминологию, лучше уточнить, что она не «стандартная» для JavaScript.
А чем она нестандартная, если для нее нужны лишь родные средства языка, без оберток, и сама идеология соответствует идеологии JS (динамическое изменение объектов)?
В итоге пришлось для каждого нового теста комментить старый код внутри тела цикла и писать новый.
Таким образом можно получить равномерное распределение по всем ветвям.
Соответственно, в каждом из тестов и на каждом прогоне ветви вызывались в одном и том же порядке и пропорциях.
я собственно и собирался во все добавить изначально, но видимо глаз замылился и не заметил
Вот вам если ДедМороз предложит совершенно бесплатно взять 10 000 рублей или 9 960, на выбор — вы что возьмете? Разница то вроде невелика.
Под заголовком методология написано.
Во-вторых, непонятно, что значит экономия на спичках.
Вот конкретно пара примеров — есть прямой цикл, есть обратный. Обратный в 2-3 раза быстрее. Да, разница в абсолютном показателе невысока, но зачем делать медленно если можно сделать быстро (при условии что порядок перебора не важен)? Инвертированный цикл даже короче в записи.
Еще пример — приватные и обычные свойства объекта. Некоторые любят понаделать приватных свойств, понаписать к нем геттеров (как привыкли в других языках), и потом копеечка к копеечке интерфейс может начать тормозить. Тесты наглядно показывают, чем это может грозить.
Логика то в конечном итоге через конструкции и выражается.
Кроме того, некоторые решения могут быть очень логичными и правильными с точки зрения архитектуры, но не оптимальными с точки зрения производительности в конкретном узком месте. Тут уже как обычно надо искать «золотую середину».
По моему опыту, нормальный менеджер проекта (что во фрилансе, что в студиях) берет на себя 90% геморроя, связанного с работой с клиентом, согласованием и написанием ТЗ, «утрясанием» всех вопросов, а также, что немаловажно, своевременным «выбиванием» денег.
И я с радостью готов отдать ему до 50% стоимости сайта за это, вместо того чтобы решать такие вопросы самому. Каждый должен делать то что у него лучше получается.
Схема, описанная в статье, уж больно ломкая, и в первую очередь из-за человеческого фактора. И по-моему, помимо всех прочих причин самая неприятная — как только такой менеджер начнет что-нибудь из себя представлять, т.е. реально разбираться в сфере создания сайтов и работе с клиентами, ему прямая дорога в руководители собственной региональной студии. Иначе кроме как дураком его назвать будет нельзя.
Пофиксил это место в статье, спасибо за полезную инфу.
Просто typeof Array, new String, new RegExp и прочие всегда выдает object, а вот typeof new Function выдает function.
Может функция это шестой, самостоятельный тип данных?
Вообще, видимо, это все вопрос терминологии и «разжевывания объяснений» )
Конструктор то все равно ручками пишем. Вот и спрашивается, чем B.parent.apply(this, arguments) лучше по сравнению с this.init_A(arguments);
Ну и соответственно для каких-то реальных действий выделить отдельный метод init.
Ведь если цель — сократить объем кода и избежать лишних сущностей, то метод с wrapper все равно не позволяет ее достигнуть.
Такая конструкция ни в каком виде не будет работать, потому что мы не можем изменить свойство [[Prototype]] у уже созданного объекта.
> Используя эту терминологию, лучше уточнить, что она не «стандартная» для JavaScript.
А чем она нестандартная, если для нее нужны лишь родные средства языка, без оберток, и сама идеология соответствует идеологии JS (динамическое изменение объектов)?