Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 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