
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не должен.
Объект не может быть сконструирован/пропущен частично на основе запредельной логики минимализма использования. Иначе на каждый инстанс объекта пришлось бы строить полный граф использования каждого члена.
На простых типах типа int такое легко делается, но не для сложного/любого объекта/структуры.
Спасибо за пояснение. Ниже написал три варианта одной и той же функции и замерил скорость их выполнения. Нигде в цикле не создаются объекты.
Неужели нужно писать подобие первой функции?! Второй же вариант - полная засада с производительностью.
Уважаемые форумчане, а какой вариант используете Вы?
Спасибо за пояснение. Ниже написал три варианта одной и той же функции и замерил скорость их выполнения. Нигде в цикле не создаются объекты.
Неужели нужно писать подобие первой функции?! Второй же вариант - полная засада с производительностью.
Уважаемые форумчане, а какой вариант используете Вы?
Все три. От случая к случаю (или от настроения?) разные.
Все три. От случая к случаю (или от настроения?) разные.
Вот теперь думаю, как найти в своих кодах использование второго варианта. Это же ужас, как оказалось.
Спасибо за пояснение. Ниже написал три варианта одной и той же функции и замерил скорость их выполнения. Нигде в цикле не создаются объекты.
Неужели нужно писать подобие первой функции?! Второй же вариант - полная засада с производительностью.
Уважаемые форумчане, а какой вариант используете Вы?
Во втором варианте у вас же все время уходит на копирование структуры на каждой итерации цикла
И по смыслу совершенно лишнее тут.
Во втором варианте у вас же все время уходит на копирование структуры на каждой итерации цикла
Это очевидно каждому.
И по смыслу совершенно лишнее тут.
Видимо, нужно догадаться, что имели в виду.
Это очевидно каждому.
Странно.
Вероятно я не так понял комментарий.
Вот этот:
>>Второй же вариант - полная засада с производительностью.
Если вам очевидно, что эта операция занимает большую часть времени, потому что по сравнению с первым и третьим содержит лишнюю дорогую операцию,
то к чему тогда был вопрос про то что этот вариант выполняется дольше всего...
Если вам очевидно, что эта операция занимает большую часть времени, потому что по сравнению с первым и третьим содержит лишнюю дорогую операцию,
то к чему тогда был вопрос про то что этот вариант выполняется дольше всего...
Речь про то, какой нативный код создает компилятор из исходного. Вместо того, чтобы во втором варианте использовать "указатель" (как это делается в третьем варианте), компилятор выполняет ровно то, что прописано в тексте второго варианта.
Ну а превосходство (пусть и малое) первого варианта над третьим не может не вызывать вопросы.
ЗЫ Предполагаю, что именно причина медлительности второго варианта является сутью медленной работы с историческими таблицами.
Речь про то, какой нативный код создает компилятор из исходного. Вместо того, чтобы во втором варианте использовать "указатель" (как это делается в третьем варианте), компилятор выполняет ровно то, что прописано в тексте второго варианта.
Ну а превосходство (пусть и малое) первого варианта над третьим не может не вызывать вопросы.Не соглашусь.
Структура это же по сути некий user defined тип данных.
Если у нас есть оператор присваивания
то все происходит согласно контракта - область данных копируется из одного места в другое.
Вы же когда один int другому присваиваете, то не ждете, то в первом int будет ссылка на второй.
Здесь тоже самое.
У вас есть полноценные объекты, чтобы делать то что вы описали.
Там все будет как вы и ждете, думаю Вы и так это прекрасно знаете.
Там все будет как вы и ждете, думаю Вы и так это прекрасно знаете.
Жду оптимизации от компилятора. Здесь про это много написали сами разработчики.
А если оптимизации нет - тогда пишем либо первый, либо третий вариант. Первый - гадость, третий - нагромождение из-за отсутствия указателей.
Сам 100% частенько писал вот так (был уверен, const подсказывает компилятору, что элементарно создать оптимальный по производительности код):
Как оказалось, компилятор не только выполняет оператор присваивания, но еще и на каждой итерации создает объект. "Что вижу, то и пою". Вот и задаюсь вопросом, где оптимизация компилятором?
Жду оптимизации от компилятора. Здесь про это много написали сами разработчики.
А если оптимизации нет - тогда пишем либо первый, либо третий вариант. Первый - гадость, третий - нагромождение из-за отсутствия указателей.
Сам 100% частенько писал вот так (был уверен, const подсказывает компилятору, что элементарно создать оптимальный по производительности код):
Как оказалось, компилятор не только выполняет оператор присваивания, но еще и на каждой итерации создает объект. "Что вижу, то и пою". Вот и задаюсь вопросом, где оптимизация компилятором?
Стало интересно.
Прогнал сейчас Ваш код.
.... <тут копия трех вариантов> ...
Результаты.
1. Компиляция без оптимизации:
2022.11.15 00:07:04.901 Test116 (RTS Splice,H1) 1. 0.00000000. Time: 755
2022.11.15 00:07:05.619 Test116 (RTS Splice,H1) 2. 0.00000000. Time: 718
2022.11.15 00:07:06.198 Test116 (RTS Splice,H1) 3. 0.00000000. Time: 579
2. Компиляция с оптимизацией:
2022.11.15 00:07:50.802 Test116 (RTS Splice,H1) 1. 0.00000000. Time: 305
2022.11.15 00:07:51.372 Test116 (RTS Splice,H1) 2. 0.00000000. Time: 569
2022.11.15 00:07:51.669 Test116 (RTS Splice,H1) 3. 0.00000000. Time: 296
Просто наблюдение..