Andrey Tsvetkov, Я лишний раз проверил и как ожидалось ноль выделений на всех бенчмарках. Приведение интерфейса к типу работает в случае чистого интерфейса, что не равно параметризованному интерфейсу. Так действительно может показаться, но отсюда и мой вопрос. Я надеялся, что все легковесные функции оптимизируются компилятором и будут переведены в inline. Хотя так и есть в assembly, но накладные расходы всё равно велики. Тут внутренняя реализация языка должна объяснить в чём дело. У меня к сожалению таких навыков нет (
По референсной ф-ции уже можно понять, что основное взаимодействие с памятью - это ридонли доступ к элементам слайса, не более. Пример максимально синтетический и простой. Хотя я уже понял что ответить на подобных вопросниках некому. Нужно стучать в двери разработчикам компиляторов...
там англосаксы в комментах говорят что этот вопрос не относится к программированию и его не нужно было задавать на SO. Это что за прикол, мне нужно напрямую разработчикам писать?
Евгений Мамонов, Вы напечатали адрес указателя. Чтобы глянуть адрес ссылки на слайс нужно убрать амперсанд. Но в целом подход то верный для переиспользования, но мне хочется чтоб inplace, т.е. без возврата из ф-ции слайс изменялся
Ну разыменовать указатель по сравнению со сложностью построения растра линии совсем уж незначительная операция, а удобство в том что не нужно каждый раз переназначать буфер в вызывающем коде. Экономия 1 строчки как минимум)
Скорее я хотел спросить, не ускальзывают ли предшествующие слайсы (которые малого размера) в кучу и не теряются ли там. Ибо буфер заменяется в результате роста элементов и слайсы выводятся из ф-ции для дальнейшего использования в общую область видимости.
В целом основная механика переиспользования здесь в этом и заключается, только я забыл добавить в начале ф-ции *buffer = (*buffer)[:0].
Евгений Мамонов, когда мы изменим слайс посредством append в теле ф-ции, то он изменит только входящую копию, а не сам слайс. А мне нужно, что бы буфер изменялся inplace (для дальнейшего переиспользования) и для удобства возвращался как значение. Если иначе, то для меня лично поведение кода будет еще более неопределённо
FanatPHP, я написал так, как выглядит функция, о которой спрошено (во вполне понятном виде). А уж если человек не различает сигнатуры и интерфейсы специфические для языка, то это его личный недуг.
На псевдокод тоже ругаетесь?
rustler2000, спасибо за пояснение. Вы имеете ввиду lock mutex в исходном коде или о каком global lock вы говорите? Просто там это сделано для безопасного доступа к кэшу в асинхронных вызовах функции Convert, насколько я понял
Adamos, структура моих данных имеет многократную вложенность, а также с массивами с переменной длиной. Я предполагаю эффективно упаковать такой тип данных в sql это боль, могу ошибаться, т.к. не особо знаком с субд. Вообще этот вопрос больше по языку Go, а не по хранению данных
Роман Мирр, я подразумеваю под динамическим архивом существующий, ранее созданный архив, в который можно добавлять/удалять (хотя бы последние) файлы.
Реализации из коробки в golang такого не предусматривают, поэтому и вопрос, может быть известны какие то библиотеки типа hdf5, но не такие громоздкие. Тем более для windows, адекватную hdf5 имплементацию go я не нашел
А по вашему что вообще происходит? Если у вас что то случилось, ты вы могли бы мне рассказать - я постараюсь вам помочь.
Про кадры в кадре это надо почитать еще. А я изложил суть в общих чертах, исключительно от прочитанного мной самим, если вам не понравился мой ответ - пожалуйтесь.
Если не понимаете метрику frame per second, обратитесь в википедию. Ясно же - кадров за секунду. Это значение надо понимать как априорное усреднение, сама механика подсчёта этой характеристики в усреднении. Не важно за секунду или за n времени. В "момент" получить количество кадров это как делить на ноль (невозможно). Если хотите расшифровать как вычисляются графики на странице по ссылке, то вам необходимо сначала понять как работает rolling window. Не переживайте, если у вас произошло что то серьёзное то знайте - не видав горя, не узнаешь и радости. Вам всего доброго, хорошего настроения и здоровья.
Что значит восстановить это вы можете глянуть в словарике, а если проблемы с пониманием контекста это уже серьёзнее чем просто не знать значение слова.
В первом и втором случае в срезе нет ни единого элемента. Разница в том, что после первого преобразования в ссылке информация на срез остается, а во втором нет.
Начинайте изучать алгоритмы и типы данных с паскаля или Си - меньше таких ответов будет.
