окей, найду — скину

окей, найду — скину

В приципе, там в строке 116 описывается оптимизация, при которой не происходит копирования, однако она происходи только в случае, если гарантированно не будет изменён нижележащий массив во время жизни строки

то есть если на него нет ссылок

точнее, нету ссылок кроме локальных в момент вызова

This is only for use by internal compiler optimizations 119 // that know that the string form will be discarded before 120 // the calling goroutine could possibly modify the original 121 // slice

Не, имеется ввиду наоборот, видимо

Что на строку больше не будет ссылок

Там примеры же есть

Что на строку больше не будет ссылок

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

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

это понятная и простая оптимизация

Которая не будет работать в случае функции конкатенации Кирилла (

Хотяяя

Да там проблема в том, что не ясна логика

И поэтому какая отпимизация что-то может ускорить - тоже непонятно

Пул нужен чтобы не аллоцировать память

Но либо потребитель памяти из пула должен о нем знать и класть обратно, либо нужно копировать

Какие еще варианты?

Да вот никаких Если бы когда кладётся буфер обратно в пул происходило бы гарантированное уничтожение буффера - я ещё понимаю правда я тогда не понимаю зачем нжуен не пошаренный пул буферов

> @twentydraft Если бы когда кладётся буфер обратно в пул происходило бы гарантированное уничтожение буффера - я ещё понимаю Тогда зачем класть?

Просто чтобы экономить на создании инстанса без самой памяти?

Вот если вынести буфер наружу, так, чтобы его использовали другие корутины, при этом у нас регулярно возникал бы избыток буферов - я ещё понимаю Но сможет ли компилятор понять, что тут можно провести оптимизацию? Дико сомневаюсь

> @twentydraft Если бы когда кладётся буфер обратно в пул происходило бы гарантированное уничтожение буффера - я ещё понимаю Тогда зачем класть?

Тогда и пул не нужен

Егоров крутой чувак. но хотелось бы чтобы что-то новое уже рассказал

а то уже сколько лет одно и то же

:(

хидден классы и старые ответы его со SO

так он и не в v8 давно

ну я видел он снова за дарт взялся

что печально

дарт в принципе нормальная штука

type system естественно говно, примерно как в ts

ну я не знаю зачем он нужен. пытаюсь понять, но не могу

но stdlib хорошая

область применения где его?

вне гугла?

В ангуларе

так-то да

ггг

неплохо

ну я бы сказал сервер сайд как node.js

ну вот может да

а как у него с математикой кстати?

как в жс или хорошо?

даже не знаю

ты имеешь ввиду что? int64?

надо покопать

ну любая математика. считать что-то.

ну так и в джсе вроде все не так плохо

ну типо интов нет

в жсе все плохо же

но по факту то,

ну Math каждый раз когда просишь, то теряешь на биндингах из жс в настоящий мир

хз что в дарте можно поменять в этом плане, но мало ли

ну это вопрос оптимизаций

ну так-то да

это спокойной и в джсе можно оптимизировать

ну Math каждый раз когда просишь, то теряешь на биндингах из жс в настоящий мир

Расскажи подробнее

но интерполяцией или аппроксимацией в жс там заниматься например не очень

а считать и моделировать надо иногда

в ноджс такие веще делегируют дальше обычно

потому что он не приспособлен

и уныл

ну вообще простая арифметика должна нормально оптимизироваться

ну простая да

не спорю

ERROR: S client not available

вот если нужны какие то струтуры, матрицы, то да

вот я про настоящую математику

но там проблема не в арифметике, а в структурах

т е дорогой доступ к структурам

не только в них же

а, ну если так то да

сначала не понял о чем ты

и это жс проблема

в дарте вероятно все же можно решить да

хотя хз. интересно бы покапаться. но жалко терять время на дарт

да не, там тоже самое в целом

то есть там полностью динамический язык

с опциональной типизацией

кстати

а вот)

не успел вопрос задать)

ты уже ответил)

скажите лучше. что еще почитать по поводу оптимизаций в JS?)

https://github.com/petkaantonov/bluebird/wiki/Optimization-killers

трай кетчи скоро будут оптимизироваться в в8

после 5.4

трай кетчи скоро будут оптимизироваться в в8

здорово это

еще бы генераторы оптимизировались

и try catch в генетраторах

и асинки

и try catch в асинках

Ломов еще давно сказал что они в в8 не оптимизируются потому что просто это не приоритетная задача

а так там проблем нет

Кстати, как я понял что-то на тему ансихронных стек трейсов планируется

в асинках и генераторах кстати наверное не все так просто

м б только в дебаге, но все равно

в хроме ж уже чото есть про это

в асинках и генераторах кстати наверное не все так просто

возможно, это зависит от реализации сильно