Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript

Было бы очень круто, будь SVG таким быстрым. В картах динамические (и не очень) объекты на картах сделаны через SVG: маршруты, линейка, полигоны (когда ищете Москву, например). Так вот, браузер довольно плохо справляется с прорисовкой/парсингом/обработкой контуров и на объемах данных подложки будет выдавать 1-2 фпс в лучшем случае.

Попробуйте найти хотя бы один карточный движок, который использует SVG для подложки. Их нет. Все рисуют или дом-тайлами, или в canvas 2d, или в webgl.

Польза строгой типизации в C++: практический опыт

Для sql уже есть готовое решение всех этих проблем и оно лежит в другой плоскости. Надо использовать prepared statements, а не конкатенировать строки.

Нужно ли чистить строки в JavaScript?

Еще интересно, что самый быстрый способ (' ' + str).slice(1) — самый быстрый ровно по той же причине почему происходит эта утечка. NewProperSubString насильно плющит строку. Итоговый перерасход памяти — 1 символ.
Остальные варианты создают куда большие промежуточные объекты.

Нужно ли чистить строки в JavaScript?

Если посмотреть в сорцы то все еще хуже:

В Factory::NewProperSubString где создается подстрока (SlicedString) исходную строку плющат в последовательную строку.

А это значит, что память течет еще сильнее при использовании ConsString'ов:

x = new (function TrackMe() {})()
x.a = 'a'.repeat(100);
x.b = 'b'.repeat(100);
x.concat = x.a.repeat(1000) + x.b.repeat(1000);
x.substr = (x.a.repeat(1000) + x.b.repeat(1000)).substring(80, 120);

На скриншоте ниже видно, что a и b — маленькие няшные ConsString (они же известны как string rope'ы). Строка из 1000 повторений каждой из них — тоже.
Но для подстроки из 40 символов такую же строку из 1000 повторений сплющило, и теперь в памяти лежит 200 кубов ради 40 символов.

Путь курильщика: как войти в профессию программиста, если ты гуманитарий

(не понял есть ли у автора акк, ну да ладно)

Настя, мне не понятно откуда у тебя уверенность, что описанный путь вхождения поможет гуманитариям:

1. Ты закончила с отличием мехмат СПбГУ, а в этом году, видимо, закончишь магистратуру. Это безусловно круто, респект и уважуха, но даже близко не путь гуманитария.
2. В Digital Banana ты учишь школьников, а они или еще не ступили ни на один из двух путей, или стоят в самом начале.
3. Твое место работы под завязку забито технарями разной степени: студентами, специалистами, магистрами и кандидатами.

И еще, пожалуйста, никогда, никому, даже вскользь, не советуй "просто почти не спать".

garbage.collect()

Я исходил из предположения, что большинство слушателей гораздо лучше знакомы с ES5. Поэтому в примере не настоящий ES6, а "ES6 собранный в ES5 вашим любимым транспилятором" (а еще потому что на слайде мало место). Но об этом, конечно, стоило упомянуть в докладе.

Бтв, конструктор класса это, на самом деле, тоже не совсем обычная функция, у нее, например, нельзя вызывать call и apply (спека).

garbage.collect()

Про Eden есть в разделе про сборку поколениями. Думайте о нем, как о половинке Semispace: все живые объекты из него копируются (эвакуируются) в другое место, а сам Eden чистится.

garbage.collect()

Тут такой момент, что сборка мусора из текущей спеки вообще ничего не гарантирует, просто потому что ее там нет. Есть пара очень абтрактных предложений в WeakMap/WeakSet (по сути гарантируется только сборка ключей в рамках одного WeakMap/WeakSet), и упоминание в NOTE'ах. Сборка мусора — это деталь имплементации движков.

tc39/proposal-weakrefs должен это изменить и привезти сборку мусора в спеку, а с ней доступность объектов и прочие интересные вещи. Но никакой отдельной гарантии на временя жизни для слабо-доступных объектов по сравнению с просто недоступными объектами там нет. (В текущей версии пропоузала слабо-доступные объекты будут жить, пока их не почистят руками, если я все правильно понял, но в этот момент они уже собраны.)

В реализациях разницы между слабо-доступным и недоступным объектом тоже нет (хотя я могу говорить уверенно только про v8). Кеш через слабую ссылку удалится при первой же сборке поколения, в котором находится кеш.

garbage.collect()

Да, согласен, пример с кешированием не правильный. Корректным был бы пример про библиотеку, которой нужно ссылаться на пользовательский объект, но не владеть им. (Кмк большая часть кейсов использования слабых ссылок — это различного рода дата-биндинги и всякое прочее зеркалирование объектов.)

И, раз уж заговорили о слабых ссылках, допишу тут вещь, которая ни в доклад ни в доклад не попала. tc39/proposal-weakrefs и node-weak дают возможность писать финализаторы. Это позволяет, например, делать всякие "защитные" механизмы, типа автоматического закрытия файлов/сокетов в ноде и удаления webgl текстур в браузере.

garbage.collect()

Да, схемки нарисованы в draw.io. Вначале я рисовал итоговую схему, потом разбивал её на слои и скрывал/показывал их при экспорте в картинку для слайда. Очень удобным оказалось то, что draw.io автоматически скрывает все стрелки, у которых скрыт хотя бы один ее объект. Это сэкономило мне кучу времени, т.к. нужно было редактировать одну схему.

Если кто-нибудь знает более удобный инструмент, поделитесь, пожалуйста.