Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
По моему, тут как раз налицо оптимизация первого случая прямого доступа к члену объекта.
Во втором случае присутствует косвенный доступ через ссылку, что при микроскопическом теле цикла закономерно занимает половину времени, увеличивая его вдвое.
Ренат, в реале происходит обработка больших массивов данных. Тест я уже упростил, чтоб просто показать проблемное место. Изначально я его делал на своих массивах и классах. Потом сократил до схемы.
то есть на самом деле имеем не просто один arr объект, а массив сложных объектов (тоже с массивами).
примерно это можно записать в схему как
Я рассуждал, что если получить ссылку на конкретный элемент массива А
то работа с параметрами A::prmX будет происходить бустрее.
Но получилось, что тягание колбасы из имён массивов
_b[i]._a[j].prmXбудет работать быстрее минимум в два раза, нежели обращение к конкретному item.
Меня это немного удивило, и стало понятно, что в ядре происходит получения некоего псевдоуказателя.
Можно ли как то оптимизировать скорость, что хотя бы уменьшить разницу в скорости?
вот так будет без ошибок
В данном тесте так не будет ошибок. Но этот способ не решает основой вопрос: почему компилятор пропускает преобразование константной ссылки объект в не константную ссылку ни выдавая ни каких ошибки и/или предупрежедений. Если это такая фича, то вопросов нет, но при этом теряется смысл модификатора const для возвращаемого типа в сигнатуре методов класса.
по моему все логично.
функции константного объекта не должны менять сам объект, следовательно они тоже должны иметь модификатор const
а по поводу
//Ошибки нет. Это НЕ правильно(CONST A* B::getA())! A* a2 = b.getA();таки да, в С++ такое не допустится. будет ошибка.
отпишите в сервисдеск.
Но получилось, что тягание колбасы из имён массивов
будет работать быстрее минимум в два раза, нежели обращение к конкретному item.
Реально получилось быстрее или это логическое построение вывода на основе других более простых случаев?
По моему, чистого доказательства на основе представленного доступа к многомерному массиву пока не представлено. Особенно с учетом наличия откровенно дорогой дополнительной функции GetPointer.
Меня это немного удивило, и стало понятно, что в ядре происходит получения некоего псевдоуказателя.
Можно ли как то оптимизировать скорость, что хотя бы уменьшить разницу в скорости?
Над оптимизацией мы постоянно работаем, но в случае со ссылками/хендлами есть системный оверхед на косвенном доступе.
В любом случае, будем пристальнее разбираться с оптимизацией такого доступа.
Реально получилось быстрее или это логическое построение вывода на основе других более простых случаев?
да, все вполне реально. тестировал на заполнении своих массивов. всегда получалось медленнее в два раза.
По моему, чистого доказательства на основе представленного доступа к многомерному массиву пока не представлено.
ну, схему его проведения и образ класса А, В и массивы выложил.
Особенно с учетом наличия откровенно дорогой дополнительной функции GetPointer.
она вызывается один раз перед входом в цикл. но в принципе для более точного теста можно её также вынести за пределы GetTickCount
ок. спасибо. это и нужно.
она вызывается один раз перед входом в цикл. но в принципе для более точного теста можно её также вынести за пределы GetTickCount
Пожелание. Можно ли в справку включить возможность увеличения масштаба текста. напр. + или - , или Ctrl+колёсико мышки.
Скорей всего это невозможно. А онлайн версия не подходит?
Вот что нашел в интернете на эту тему - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907
UPDate Еще http://forum.ixbt.com/topic.cgi?id=23:39211
Скорей всего это невозможно. А онлайн версия не подходит?
Вот что нашел в интернете на эту тему - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907
UPDate Еще http://forum.ixbt.com/topic.cgi?id=23:39211