С другой стороны, такая оценка нужна ровно в двух случаях: либо если вы собираетесь сделать дамп в памяти и хотите понять, сколько её надо резервировать, либо если вам надо строить внутренние таблицы релокации внутри такого дампа.
Ну звучит как достаточно важная оптимизация, но потенциально время самого GetBufLen может ее нивелировать.
У меня вопрос возник по поводу функций GetBufLen и SkipToEnd. В общем случае ведь, чтобы понять размер буфера требуемый для хранения структуры или пропустить ее в общем буфере. Нужно пройтись вглубь по всей структуре, разве это не будет равносильно по коду и времени сериализации/десериализации?
Пример есть класс, в котором вектор каких-то объектов.
Чтобы узнать размер буфера требуемого для хранения объекта этого класса, нужно узнать размер вектор, который известен, только в рантайме, и посетить каждый елемент этого вектора, так как внутри тоже могут быть динамические объекты. При пропуске, нужно прочитать из буфера размер вектора, затем прочитать каждый элемент, потому как из-за динамических объектов внутри, каждый элемент может быть разного размера и сколько пропускать не понятно.
Дополнительно про упакованные числа. Чтобы понять сколько байт нужно пропустить для числа в буфере, его ведь тоже нужно прочитать сначала?
Ну как зачем? Просто опытом поделится, вдруг кому-то будет полезно. Оно же тут не толкается, считаю пусть будет yet another статья или библиотека, чем не будет.
Вектор имеет размер и емкость. Тут речь про статическкую емкость, а размер как раз может меняться. Для std::vector ближайшим аналогом будет, если вы изначальное сделаете reserve и при добавлении элементов сами будете следить чтобы size() не превышал capacity(). Но std::vector память выделит в куче.
Здорово что тут получилось избавиться от аллокации. Но главный минус этой реализации, пользователю требуется подумать о времени жизни объектов. Если расширить функционал до использования с лямбдами, то станет очевидно, что такая реализация не так широко применима. Сам сейчас экспериментирую с разными подходами по теме.
Может достаточно определить заранее будут одинаковые объекты в программе/игре и при удалении очередного объекта не удалять его, а просто пометить удалённым? Придёт другой объект и займёт уже подготовленную память, да, данные перезаписать придётся, но зато "тормошить" память постоянно не надо.
А разве для этого как раз и не делают кастомные аллокаторы с пуллами памяти? На выделял на кучу объектов, те которые надо освободили, но не освободили на самом деле, а только пометили, а потом переиспользовали. Но конструторы и деструкторы вызывваются по настаяшему, а конкретные классы даже не подозревают каким образом для них добывают память.
> оно не зависло навсегда и не тормозило при наличии хотя бы 2 юзеров
А есть какое-то сравнение с питоновскими либами? Или тут в принципе бенчмаркать бессмысленно так-как очень быстро упремся в скорострельность серверов телеграмма?
У меня в универе в ВКР была часть с проектированием линейного привода станка. Как раз использовал линейный двигатель. Подробностей не вспомню, но линейный я тогда не выбрал, так как на больших длинах есть проблема с провисанием стержня. Её пытаются решить компромисными путями, размыкают цилиндр и делают П образные катушки. А ещё с плоскими двигателями есть проблема, с тем, что две части пытаются оттолкнуться друг от друга.
А для выбора функций нельзя сделать чекбоксы для каждой и при отключении удалять функционал из браузера вообще, а при включении снова ставить. Хотя тогда это будут просто расширения. Точно, а почему вы все эти календари, почты, и переводчик не сделали обычными расширениями?
Я про гонку не понял.
Мы там вроде как не ждем окончания горутин. Логично, что пока мы читаем читаем из одной переменной, горутина поменяет значение и значение в синглтоне изменится.
Но если мы просто дождемся окончания всех горутин, то значение будет одинаковое.
Как мьютекс тут влияет вообще?
Любил темные темы, пока не столкнулся с проблемой. На работе днем солнце высвечивает монитор и нифига не видно. Приходится использовать светлую тему.
Еще заметил, что с темной темой легче засыпается при чтении скучной документации.
А вот еще не понятно. Раз в 20 минут данные, это не слишком редко, а если датчик умрет вы через сколько узнаете, что что-то не так? За это время на там все не замерзнет/перегреется?
У меня в транспорте, как правило, стоять нормально проблема, а вы говорите читать. Руки заняты тем, чтобы удержаться самому, на телефон конечностей не остается. Сегодня к обычной давке добавилось еще и то, что кто-то решил помыть полы накануне заморозков. И это я еду еще не в самый час пик, когда нет пробок. В автобусе около 40 минут в один конец, но это как правило худшие 2 раза по 40 минут в день.
Ну звучит как достаточно важная оптимизация, но потенциально время самого GetBufLen может ее нивелировать.
У меня вопрос возник по поводу функций GetBufLen и SkipToEnd. В общем случае ведь, чтобы понять размер буфера требуемый для хранения структуры или пропустить ее в общем буфере. Нужно пройтись вглубь по всей структуре, разве это не будет равносильно по коду и времени сериализации/десериализации?
Пример есть класс, в котором вектор каких-то объектов.
Чтобы узнать размер буфера требуемого для хранения объекта этого класса, нужно узнать размер вектор, который известен, только в рантайме, и посетить каждый елемент этого вектора, так как внутри тоже могут быть динамические объекты.
При пропуске, нужно прочитать из буфера размер вектора, затем прочитать каждый элемент, потому как из-за динамических объектов внутри, каждый элемент может быть разного размера и сколько пропускать не понятно.
Дополнительно про упакованные числа. Чтобы понять сколько байт нужно пропустить для числа в буфере, его ведь тоже нужно прочитать сначала?
Ну как зачем? Просто опытом поделится, вдруг кому-то будет полезно. Оно же тут не толкается, считаю пусть будет yet another статья или библиотека, чем не будет.
Вектор имеет размер и емкость. Тут речь про статическкую емкость, а размер как раз может меняться. Для std::vector ближайшим аналогом будет, если вы изначальное сделаете reserve и при добавлении элементов сами будете следить чтобы size() не превышал capacity(). Но std::vector память выделит в куче.
Ну например если мы знаем что элементов может быть не больше чем N, но не знаем сколько именно, и динамические аллокации делать не хочется.
Здорово что тут получилось избавиться от аллокации. Но главный минус этой реализации, пользователю требуется подумать о времени жизни объектов. Если расширить функционал до использования с лямбдами, то станет очевидно, что такая реализация не так широко применима.
Сам сейчас экспериментирую с разными подходами по теме.
А разве для этого как раз и не делают кастомные аллокаторы с пуллами памяти? На выделял на кучу объектов, те которые надо освободили, но не освободили на самом деле, а только пометили, а потом переиспользовали. Но конструторы и деструкторы вызывваются по настаяшему, а конкретные классы даже не подозревают каким образом для них добывают память.
А я теперь хочу статью про другие тонкости, например деградацию move-семантики.
Да. Переходя по ссылку нужно научится закрывать глаза на пафоc.
А вот вы про
А есть какое-то сравнение с питоновскими либами? Или тут в принципе бенчмаркать бессмысленно так-как очень быстро упремся в скорострельность серверов телеграмма?
А я не понял почему strelen() не выкидывается. Это по стандарту так?
Проверил что дает бесконечный цикл.
https://godbolt.org/z/KcPvfWcnT
У меня в универе в ВКР была часть с проектированием линейного привода станка. Как раз использовал линейный двигатель. Подробностей не вспомню, но линейный я тогда не выбрал, так как на больших длинах есть проблема с провисанием стержня. Её пытаются решить компромисными путями, размыкают цилиндр и делают П образные катушки. А ещё с плоскими двигателями есть проблема, с тем, что две части пытаются оттолкнуться друг от друга.
Спасибо, буду знать
Мы там вроде как не ждем окончания горутин. Логично, что пока мы читаем читаем из одной переменной, горутина поменяет значение и значение в синглтоне изменится.
Но если мы просто дождемся окончания всех горутин, то значение будет одинаковое.
Как мьютекс тут влияет вообще?
Еще заметил, что с темной темой легче засыпается при чтении скучной документации.
Это значит вам крупно повезло. Не подскажите какой город, может мне пора дислокацию сменить?