Это не так. v8 очень хорошо оптимизирован, и не особо сложными телодвижениями там можно достичь очень больших скоростей (как, например, показано в этой статье). Вполне можно посмотреть машинный код того, что получится — и вряд ли вы сделаете заметно быстрее.
Если конкатенация множества мелких строк — да, [].join.
Строки в JS, как и во многих других языках, immutable и pooled. += создаёт новую строку и добавляет её в пул. Причём строки ссылаются на старые, которые уже были в пуле — поэтому если мы строим посимвольно огромную строку — это худшее, что можно придумать — все её компоненты будут в пуле (пока мы её не нормализуем руками или не освободим, конечно).
Про множество больших строк — не скажу точно, надо проверять для вашего конкретного юзкейса, это зависит от того, каким образом вы их собираете и что вы с ними делаете потом. Например, если у вас есть строка A в 20 MiB, строка B в 20 MiB, и вы сохраняете две строки C = A + B и D = B + A + B + A + B, у вас всё равно в сумме получается занято 40 MiB — тут лучше складывать. Такое поведение оптимально для большинства частых случаев, кроме тех, когда складывается именно очень большое количество мелких строк — тогда накладные расходы становятся очень большими.
CloneFactory.prototype = Object.create(null); даёт ещё 10-15% прироста в скорости.
Правда, у вас при этом не будет наследуемых от Object методов, но в оптимизированном коде они не очень-то и нужны и без них можно обойтись.
Справедливости для, JSON.parse и JSON.stringify поддерживают replacer/reviver, которые как раз и нужны, чтобы сохранить дополнительные типы. Но тогда всё будет заметно медленнее работать, скорее всего.
Починили, по крайней мере лента действительно не переполняется
и (оффтопик: если не ставить разделитель между цитатами, ломается парсер маркдауна, пойду, багрепорт напишу)
Да, только при вставке ссылки вместе с этим оффсетом лента всё равно грузилась с начала. Сейчас пофиксили, грузится с нужного места, только с обрезанным началом.
Если всё так, то это похоже на то, что они выкатили сырую версию, а потом стали править на живую. Это очень нехорошо, и обычно это ошибка управления — то ли нашли разработчиков подешевле, то ли поставили очень жёсткие дедлайны, и уж во всяком случае не провели должного тестирования.
Но то, что получилось после исправлений — у меня выглядит вполне прилично, и заметно лучше того, как было раньше.
Честно говоря, я не знаю, как у них получилось на планшете — не проверял. Но обычно в таких случаях тач-устройства детектируют и либо сразу показывают, либо на какое-то другое действие вешают. Они не догадались, что ли?
Неожиданная неприятность произошла и с бесконечным скроллингом. Он грузит всё больше и больше картинок до тех пор, пока браузер не сожрёт всю память и не подвиснет. В итоге у людей начали возникать проблемы при попытке прокрутить более 1000 картинок за раз, при том что полная лента запросто содержит десятки тысяч плиток.
Не воспроизводится, картинки вне области видимости выгружаются. Починили?
Инновационный алгоритм укладки плитки оказался с явным изъяном — почему-то плитки частенько дублировались.
Раньше этого не было, а теперь появилось? Это точно не копии картинки в разных местах? В любом случае, если это так — похоже на тривиальный баг. Но я его не заметил. Починили?
Просмотр невозможно продолжить с того места, на котором остановился, так же как и переслать кому-либо ссылку на это место.
Неправда. Адресную строку смотрели? Там динамически со скроллингом меняется offset, и по ссылке открывается ровно в том месте. Не в виде скролла, правда, а просто часть результатов сверху пропущена — можно было бы и аккуратнее сделать, да, но ссылка пересылается и место запоминается.
Исчезли подписи. Ещё раз гляньте на КДПВ — видно, что текст полностью убрали, чтобы он не мешал плиткам. И если раньше можно было видеть информацию по каждой работе — название, автор, количество комментариев и т.д., то дизайнеры новой ленты решили, в полном соответствии с нынешней модой, сделать равнение на контент и убрать всё лишнее.
Всё это появляется при наведении мышки. Не вижу повода для паники.
Вопреки заявлениям, плиток на экран стало влезать не больше, а меньше, т.к. размер очень уж сильно вырос.
Теперь я могу видеть картинки, а не крошечные миниатюры, и могу щёлкать в два раза меньше — лучше видно, что интересно, а что стоит пропустить.
Дизайн потерял целостность, т.к. нововведение затронуло только ленты поиска и просмотра, галереи же остались со старым дизайном.
Я не понял — это в вашем контексте плохо или хорошо? Было бы лучше, если бы они не только на ленту это накатили, а сразу на всё?
И галку вернули — это хорошо. Но для предотвращения шитсторма им бы стоило вначале выкатить это как тестовую версию и добавить кнопку перехода на неё, конечно же. А не наоборот.
И да — интерфейс девиантарта был страшноватым и медленным. Теперь стало получше, искать что-то можно гораздо быстрее. Но это лично моё мнение.
Если речь идёт про Велобайк, то там «Тройка» + пин-код служат всего лишь альтернативным идентификатором пользователя. Деньги списываются напрямую с привязанной банковской карты, «Тройкой» оплатить нельзя.
Я к тому, что если идёт разговор о «мировом рекорде беспроводной передачи данных» в таком ключе, то 160 бит в cекунду на 20 миллиардов километров мне кажутся куда лучшим кандидатом.
Смс приходит, но не всегда — мне, например, один раз не пришло — проблемы на станции. Но звонок в поддержку помог.
«Возврат ОК», кстати, сопровождается звуковым сигналом.
Я имел ввиду скорее сторону не пользователей, а компании (учитывая описанные в статье опасения) — у самой компании реально такой тариф есть, люди им пользуются, при этом компания на нём не разорилась и сети Мегафона не перегрузило.
Вы ошибаетесь.
evalнаследует текущую область видимости, а уnew Functionона своя и в неё не попадает всё окружение, как вeval.Это не так. v8 очень хорошо оптимизирован, и не особо сложными телодвижениями там можно достичь очень больших скоростей (как, например, показано в этой статье). Вполне можно посмотреть машинный код того, что получится — и вряд ли вы сделаете заметно быстрее.
По поводу «статичности» и того, как работает оптимизатор внутри — см, например http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.html.
Это не совсем верно. Я ссылочку ниже привёл на lz-string, посмотрите.
Если конкатенация множества мелких строк — да,
[].join.Строки в JS, как и во многих других языках, immutable и pooled.
+=создаёт новую строку и добавляет её в пул. Причём строки ссылаются на старые, которые уже были в пуле — поэтому если мы строим посимвольно огромную строку — это худшее, что можно придумать — все её компоненты будут в пуле (пока мы её не нормализуем руками или не освободим, конечно).Про множество больших строк — не скажу точно, надо проверять для вашего конкретного юзкейса, это зависит от того, каким образом вы их собираете и что вы с ними делаете потом. Например, если у вас есть строка A в 20 MiB, строка B в 20 MiB, и вы сохраняете две строки C = A + B и D = B + A + B + A + B, у вас всё равно в сумме получается занято 40 MiB — тут лучше складывать. Такое поведение оптимально для большинства частых случаев, кроме тех, когда складывается именно очень большое количество мелких строк — тогда накладные расходы становятся очень большими.
См. https://github.com/pieroxy/lz-string/issues/46#issuecomment-80531018, например — это пример посимвольной сборки был.
Кстати, о птичках (то есть попугаях).
CloneFactory.prototype = Object.create(null);даёт ещё 10-15% прироста в скорости.Правда, у вас при этом не будет наследуемых от
Objectметодов, но в оптимизированном коде они не очень-то и нужны и без них можно обойтись.Держите: https://jsfiddle.net/1sq3uhmo/.
Справедливости для,
JSON.parseиJSON.stringifyподдерживаютreplacer/reviver, которые как раз и нужны, чтобы сохранить дополнительные типы. Но тогда всё будет заметно медленнее работать, скорее всего.Да-да. =)
Вот тут ещё разобран тот самый код, со ссылкой в т.ч на статью Конрода.
А со строками — вы так, главное, что-то действительно большое и/или долгоживущее не стройте. Ну или нормализуйте её потом.
Идея неплохая, да.
Не надо так пугать =). Через
new Functionже.Посмотрел код — конкатенировать много мелких строк через
+=не очень хорошо, но вы результат не храните, как я понял — так что это несущественно.Но это далеко не самая злая оптимизация, что я видел. Ещё вот такие штуки бывают:
https://github.com/petkaantonov/bluebird/blob/ee247f1a04b5ab7cc8a283bedd13d2e83d28f936/src/util.js#L201-L213
и (оффтопик: если не ставить разделитель между цитатами, ломается парсер маркдауна, пойду, багрепорт напишу)
Если всё так, то это похоже на то, что они выкатили сырую версию, а потом стали править на живую. Это очень нехорошо, и обычно это ошибка управления — то ли нашли разработчиков подешевле, то ли поставили очень жёсткие дедлайны, и уж во всяком случае не провели должного тестирования.
Но то, что получилось после исправлений — у меня выглядит вполне прилично, и заметно лучше того, как было раньше.
Честно говоря, я не знаю, как у них получилось на планшете — не проверял. Но обычно в таких случаях тач-устройства детектируют и либо сразу показывают, либо на какое-то другое действие вешают. Они не догадались, что ли?
Знаете, а ведь неплохо получилось.
Не воспроизводится, картинки вне области видимости выгружаются. Починили?
Раньше этого не было, а теперь появилось? Это точно не копии картинки в разных местах? В любом случае, если это так — похоже на тривиальный баг. Но я его не заметил. Починили?
Неправда. Адресную строку смотрели? Там динамически со скроллингом меняется offset, и по ссылке открывается ровно в том месте. Не в виде скролла, правда, а просто часть результатов сверху пропущена — можно было бы и аккуратнее сделать, да, но ссылка пересылается и место запоминается.
Всё это появляется при наведении мышки. Не вижу повода для паники.
Теперь я могу видеть картинки, а не крошечные миниатюры, и могу щёлкать в два раза меньше — лучше видно, что интересно, а что стоит пропустить.
Я не понял — это в вашем контексте плохо или хорошо? Было бы лучше, если бы они не только на ленту это накатили, а сразу на всё?
И галку вернули — это хорошо. Но для предотвращения шитсторма им бы стоило вначале выкатить это как тестовую версию и добавить кнопку перехода на неё, конечно же. А не наоборот.
И да — интерфейс девиантарта был страшноватым и медленным. Теперь стало получше, искать что-то можно гораздо быстрее. Но это лично моё мнение.
Скорее, как минимум 1200.
Нет, спасибо.
Если речь идёт про Велобайк, то там «Тройка» + пин-код служат всего лишь альтернативным идентификатором пользователя. Деньги списываются напрямую с привязанной банковской карты, «Тройкой» оплатить нельзя.
Мораль: не подписывайте всякую ерунду, не читая её очень внимательно. Ну как обычно, в общем-то.
Но пример очень наглядный, спасибо.
Вояджер 1 на 20 млрд км от Земли сейчас, даже чуть больше :-). См. http://voyager.jpl.nasa.gov/
Я к тому, что если идёт разговор о «мировом рекорде беспроводной передачи данных» в таком ключе, то 160 бит в cекунду на 20 миллиардов километров мне кажутся куда лучшим кандидатом.
А не 20 млрд километров и 160 бит в секунду?
«Возврат ОК», кстати, сопровождается звуковым сигналом.
С этим согласен, да, о такой ситуации не подумал.
Я имел ввиду скорее сторону не пользователей, а компании (учитывая описанные в статье опасения) — у самой компании реально такой тариф есть, люди им пользуются, при этом компания на нём не разорилась и сети Мегафона не перегрузило.