Реалити Разработка

Приветствую!

Решил запустить стрим своей разработки. Можете наблюдать в реальном времени то чем я занимаюсь, писать в чат, буду попутно рассказывать и объяснять всё, если будут вопросы пишите в чат. Так же можете тут обсуждать и задавать вопросы, тоже буду отвечать по мере возможности.

Мой RUTUBE канал

0

Сообщение от voral А могу вообще просто конфиг хранить. Т.е. не будет ни чего дополнительного Добавлено через 26 секунд "претензии" понял.. завтра несколько изменю

Это не претензии. У тебя код нормальный для како-то простого сайта, с передачей в конструкторе функции, так и должно быть чтобы у каждой кнопки была своя функция, а не одна на всех("просто конфиг хранить").

Но я лично так бы никогда не делал, универсальности никакой(к примеру в Vue, React основные функции в библиотеке, а пользователь создаёт лишь объекты с свойствами, ну некоторые свои обработчики), а тут под каждый чих(если ещё другое событие и тд.) нужно добавлять в класс(компонента кнопки...) новые свойства и обработчики.. короче это очень примитивный код ИМХО. Если прикинуть код класса это ~1000 байт на 100000 это ~100Mb + объекты навешивания событий и тд. + если страница с картинками, видео, это наверно будут жуткие тормоза для пользователя.. даже если и нет я всё равно такой код бы не стал писать, он ужасен.. годный только для командной разработки так как интуитивно понятен, в остальном шлак(опять же ИМХО)

0

Сообщение от pgb У тебя код нормальный для како-то простого сайта

Что значит одна на всех? Обрати внимание. Здесь у каждой кнопки своя функция (то, что она похожа ни чего не значит). Более того, когда одна функция у всех кнопок ни кто не вешает обработчик на каждую функцию - вешают обработчик на родителя. У этого даже термин есть "делегирование".

В чем ограничение для больших проектов у моего наброска?

Сообщение от pgb а тут под каждый чих(если ещё другое событие и тд.) нужно добавлять в класс(компонента кнопки...) новые свойства и обработчики..

Чего? Зачем? Что значит "чих"? Приведи пример задачи.

Тебя не должно смущать наличие конфига, если тебе он кажется сложным - можно сделать это на уровне дом элементов. (хотя это будет уже бред). Можно добавлять через методы. В моем подходе это вообще не важно.

Сообщение от pgb Если прикинуть код класса это ~1000 байт на 100000 это ~100Mb + объекты навешивания событий и тд. + если страница с картинками, видео, это наверно будут жуткие тормоза для пользователя.

Хрена себе у тебя познания. Освой уже инструменты встроенные в браузеры. Завтра будет тебе тест и мини урок как посмотреть сколько памяти съедается. Ты реально думаешь, что на столько идиоты разработчики браузеров и языка JS?

Сообщение от pgb даже если и нет я всё равно такой код бы не стал писать, он ужасен.

Правильно ли я понял: ты считаешь его ужасным потому, что считаешь что 10000 кнопок в памяти займут 100Mb ?

0

Итак. Обещал - сделал.

Первая часть: изменения тестового прототипа редактора

Код сюда уже копипастить не буду - гораздо легче его смотреть на том же github

Пощупать прототип редактора можно здесь

По "заявкам трудящихся":
- убрал "лишние переменные"
- у всех кнопок теперь явно свои обработчики
- добавил динамическое добавление кнопки на тул бар
- добавил, для демонстрации, как кнопка через событие может "попросить удалить себя" (Add italic)
- добавил индикатор изменений редактируемого текста ("С MutationRecord {type: 'characterData'}" - не совсем понял что это кардинально меняет, но у меня нет нормального ТЗ отвечающего на вопрос "что должен делать", а только "что должен использовать")


От себя добавил стиля.

Вторая часть. Тесты.

Итак смотреть тесты можно здесь

Там три варианта:
1 Pair - генерируется и DOM элемент и элемент обертка.
2 DOM only - генерируется только DOM элемент
3. Empty - ни чего не генрится - можно посмотреть что требует пустая страница

Генерируется 100000 кнопок. Генерацию списка кнопок вынесена за пределы первого теста. По сути не важно как мы их получили - возможно от АПИ прилетел список. По уверениям ТС первый вариант должен сжирать на 100Мб больше памяти. Ну и по времени должны быть жуткие тормоза.

Рекомендуемые условия тестирования. Браузер в режиме инкогнито, каждую страницу погонять раз 5 и посмотреть на среднее значение.

Тесты (от простых):
1. Смотрим в консоль. и там время в милисекундах. Время которое выполняется функция генерации всех кнопок
2. На вкладке Сеть есть простая статистика
3. Вкладка Memory тут рекомендую Allocation sampling. Запускаем запись, обновляем страницу, останавливаем запись. И так по 5 раз для каждой. На построенном графике особое внимание уделяем блокам отмеченным как createPair и createDOMonly (в одном тесте одна, в другом - другая)...


Т.е. там не то что нет разницы в 100mb там вообще нет 100Mb. И разницы нет значительной не по производительности ни по памяти. (кнопки, кстати, все действуют - и пишут в консоль каждая свое сообщение)

Добавлено через 46 секунд
pgb, итак. что по данному этапу. какие замечания и комментарии?

9

voral, два кофе этому господину, реально заморочился

0

Welemir1, только отдачи от этой замороки не будет. pgb превратился в цифрового попугая, который по кругу одну и ту же тему гоняет: "Да вы ничего не понимаете, да вы все дураки и подстилки корпоративные". С таким индивидом бесполезно пытаться конструктивный диалог выстроить и какие-то аргументы и код приводить. Он всё равно будет недоволен.

4

Сообщение от Usaga только отдачи от этой замороки не будет

ну, на самом деле, отдача для меня есть. У меня есть пробелы в знании ванильного JS в т.ч. с той же событийной кухней. Потому "заморачиваюсь" ровно до той степени, на сколько мне интересно. Для примера сейчас мой редактор умеет выделять италиком и болдом. Но топорно - без учета нюансов. Это уже делать не интересно: просто алгоритм и время. В "не реальном" же проекте в подобной ситуации (если представить, что возникли объективные причины, не использовать готовое хорошо отлаженное решение) взял бы vue и не парился. А так, лично для себя, некоторые моменты прояснил.

0

Usaga, все верно, не в коня корм, Воралу самому просто интересно все это навертеть) А наш маэстро опять скажет, что это другое, не так поняли, код примитивен и в реалите разработке (это такая где один неуч пишет то, что никому не нужно) так не делают.

2

Сообщение от voral У меня есть пробелы в знании ванильного JS в т.ч. с той же событийной кухней.

Посмотри на pgb и осознай, что у тебя проблем с ванильным JS нет

Сообщение от voral взял бы vue и не парился

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

1

Сообщение от voral там вообще нет 100Mb

100а там нет, есть 20Mb, но после каждого обновления страницы объём заполненной оперативки растёт..
Это говорит об утечке памяти. Если пользователь несколько страниц посмотрит куда ни шло, а если будет находится на сайте некоторое время, то через это время ему придётся перезагружать комп..

Добавлено через 55 секунд

Сообщение от Usaga у тебя проблем с ванильным JS нет

однозначно

0

Сообщение от pgb но после каждого обновления страницы объём заполненной оперативки растёт.. Это говорит об утечке памяти.

Нет, не говорит. Это говорит о том, что GC не бежит чистить кучу как только, так сразу. Как он почти в любых средах и работает.

2

Сообщение от pgb 100а там нет, есть 20Mb, но после каждого обновления страницы объём заполненной оперативки растёт.. Это говорит об утечке памяти. Если пользователь несколько страниц посмотрит куда ни шло, а если будет находится на сайте некоторое время, то через это время ему придётся перезагружать комп..

Для начала. Между вариантам ты разницу увидел? тест ведь сравнительный в первую очередь

0

Сообщение от Usaga Вместо того, чтобы пытаться всему миру что-то доказать, можно же просто... решить задачу и пойти дальше.

Я уже говорил, что ничего не имею против, вас это устраивает вперёд и с песней. Меня существующие инструменты конструкторы не устраивают, вот и всё. А чтобы мою задачу решить нужно свой инструмент разработать.

0

Ну а далее.
1 Про GC расскажешь как он работает в общих чертах?
2 Твою теорию легко можно проверить
3 Это как то связано с необходимостью добавлять какое то специализированное хранилище калбеков?

Добавлено через 4 минуты

Сообщение от pgb Я уже говорил, что ничего не имею против, вас это устраивает вперёд и с песней. Меня существующие инструменты конструкторы не устраивают, вот и всё. А чтобы мою задачу решить нужно свой инструмент разработать

Если ты не понял. Твой "инстурмент" ни чего лучшего не покажет на этом же тесте по определению. Тебе точно так же потребуется как и и в тесте DOM onlу создать эти же самые элементы DOM.

кроме того. если я правильно понимаю (ты ведь пока так и не смог пояснить внятно зачем тебе единое хранилище обработчиков) - ты хочешь по какому то событию снимать их с прослушки одним махом. И вот тут тебе можно легко на основе моего теста. Сделать еще один. Сними обработчики скриптом с этих кнопок. И оцени "производительность" решения к которому ты стремишься. Это очень наглядно покажет тебе, что ты наоборот убиваешь производительность.

Добавлено через 5 минут

Сообщение от pgb Я уже говорил, что ничего не имею против, вас это устраивает вперёд и с песней.

А дело тут вообще не в инструментах. А в том, что тест наглядно показывает твое заблуждение по производительности.


Ну и вопрос остается открытым. Что в моем прототипе редактора еще не сделано, чтобы была необходимость специального хранилища обработчиков.


Снимать, кстати, которые "чохом" совершенно не корректная идея для продукта класса "фреймворк". Вот есть программист Вася согласившийся создавать сайты на твоем решении. У него есть некий обработчик события который согласно бизнес логике его приложения не постоянно висит, а в соответствии с неким состоянием приложения (как пример фоновый опрос АПИ и по результатам ответа)... А вот твой фреймворк решил что пора все обработчики событий снять... снимает и его.... а как потом вернуть? Вернешь так же чохом? А если по логике работы его приложения он уже должен быть уже снят?

Именно по этому за постановку и снятие обработчиков должны отвечать именно те сущности которым это положено по логике приложения. Т.е. одна и та же сущность и ставит и снимает.....

0

Сообщение от voral Между вариантам ты разницу увидел? тест ведь сравнительный в первую очередь

Разница в 5Mb при создании только кнопок 15Mb потребляется, хотя по идее вообще 0 должно быть, опять же утечка памяти, ах да это ж не Rust, тут через некоторое время сборщик мусора только удаляет

0

Сообщение от Usaga Нет, не говорит. Это говорит о том, что GC не бежит чистить кучу как только, так сразу. Как он почти в любых средах и работает.

Вот сейчас он узнает о GC и скажет, что js ему теперь не подходит и нужно создавать свой язык)

0

Сообщение от pgb Разница в 5Mb при создании только кнопок 15Mb потребляется, хотя по идее вообще 0 должно быть

Надеюсь ты несколько раз тест прогнал.

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

И тут речь не о готовых решениях. А об опыте накопленном годами. Код не обязательно копировать или делать похожим, просто достаточно учитывать опыт.

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

0

Сообщение от pgb хотя по идее вообще 0 должно быть

Почему? Хочется ваше мнение узнать.

0

Сообщение от pgb Если пользователь несколько страниц посмотрит куда ни шло, а если будет находится на сайте некоторое время, то через это время ему придётся перезагружать комп..

Итак. Запустил тест. поставил на обновление раз в 5 сек. пошел заниматься своими делами. Прошло 55 минут.

Комп живой, все кнопки на тестовой странице мгновенно реагирую на клик память порядка 60мб....... Опять я что то не так сделал?

0

Сообщение от voral Опять я что то не так сделал?

Делай как умеешь Я же тебя не заставляю делать как я, почему вы меня заставляете делать как вы.

Сообщение от gogolik Почему? Хочется ваше мнение узнать.

По идее DOM от кода JS существуют отдельно(имеется виду размещение в памяти), я смотрел на затраты памяти JSом
В цикле генерации кнопки создаётся объект кнопки и отправляется в DOM .append, память объекта в JS должна быть освобождена и тд. затрат практически 0, но в JS есть сборщик мусора и он действует с опозданием поэтому и происходит утечка памяти. Хотя можно в цикле освобождать память от объекта переданного в DOM, но такой пустячок "гуру" игнорируют

Добавлено через 6 минут

Сообщение от Custos Вот сейчас он узнает о GC и скажет

То есть вас не смущает то, что я ранее о нём уже говорил, что он влияет на утечки памяти, но вы думаете, что я о нём только что вот узнал

0

Сообщение от pgb Делай как умеешь Я же тебя не заставляю делать как я, почему вы меня заставляете делать как вы

Ни кто ни кого не заставляет ни чего делать. Просто среди людей думающих и интерсующихся что и как работает под капотом считается нормой на примерах подтверждать или опровергать слова или гипотезы. Тем более проверка гипотезы совершенно простая.

Ты сначала предположил, что с моим подходом (каждая кнопка DOM имеет по сути обертку) - потребление памяти значительно вырастит. Если быть точным "100000 кнопок дадут 100Мб" - я опровег эту гипотизу тестом. (и по производительности тоже)

Следующая твоя гипотеза. Если пользователь будет долго находится на этой странице - то компьютеру поплохеет вплоть до необходимости перезагрузки компьютера. Я сделал тест, причем постоянно перегружая страницу. Тест, кстати, до сих пор работает, и я совершенно без проблем работаю на этом компе. (Уверяю PHPStorm быстро бы возмущаться стал если бы ощутил нехватку ресурсов, да и компу у меня уже более 10 лет). Вот я и уточнил: все ли я выполнил так, чтобы сбылся твой прогноз. Или я что то сделал, что обходит "должное поведение"?

Добавлено через 2 минуты

Сообщение от pgb То есть вас не смущает о том, что я ранее о нём уже говорил

Все давно уже привыкли, что если ты о чем то говоришь, то это не значит, что ты это знаешь. Увы, но пробелы в знаниях проявляются и сильно заметны.

Добавлено через 3 минуты
И все же ты опять проигнорировал главный вопрос про специальное "хранилище" обработчиков событий. Чего в моем редакторе не хватает, чтобы он потребовался? Можешь ли рассказать о ситуации, когда он требуется? (не то что "когда надо отключить все обработчики", а что за ситуация когда надо это сделать)

6