Статичный по сравнению с глобальным с точки зрения скорости и потребления пространства в C
Первый создает промежуточную строку (которая будет назначена на s после операции +), а вторая - нет (зависит от емкости строки).
Сложность в худшем случае одинакова в обоих случаях, в лучшем случае это просто копирование новой строки для второго случая с полной копией обеих строк для первого случая (+ выделение памяти и освобождение). [115 ]
Тот факт, что ваш get TLE (Time Limit Exceeded), вероятно, связан с этим наихудшим случаем, который всегда копирует огромные строки, а не просто добавляет что-то к существующей (без перераспределения). Как и в случае с вектором, в string должна быть некоторая эвристика, чтобы заранее получить адекватную пропускную способность.
Как сказал @Slava, этот пример должен быть написан по-другому, я полагаю, что реальный код отличается.
6 ответов
Нет никакого различия для пространства, они берут ту же сумму.
Но существует различие в скорости: статичный быстрее.
Конечно, доступ к памяти к переменной является для глобального и статического тем же. Но компилятор может оптимизировать, когда Вы имеете статичный. Когда это компилирует модуль, это знает, что никакой вызов функции к функции вне модуля не может заменить статическую переменную. Таким образом, это знает точно, что происходит, и может, например, сохранять его в регистре по вызовам функции. Когда это глобально, и Вы вызываете функцию от другого модуля, компилятор не может знать то, что это делает. Следовательно он должен предположить, что функциональные доступы переменная и изменяют его, приводя к хранилищу и перезагрузке.
С gcc можно передать все .c источники одновременно, таким образом, это может затем также видеть то, что происходит в вызовах функции с функциями от различных модулей. Чтобы заставить его работать, необходимо передать помимо всех .c файлы сразу -combine и -fwhole-program. -fwhole-program делает все globals помехи (не модуль статическая но статичная единица компиляции, т.е. весь данный .c файлы вместе). -combine делает межмодульный анализ.
Потребление пространства: в основном никакое различие. Единственное время там было бы проблемой пространства, то, если Вам удается получить тот же блок статических данных, скрытых в объектных файлах N, затем Вы получаете коэффициент умножения N, где у Вас могла бы быть всего 1 копия, если бы это была единственная глобальная часть данных. Однако это - неправильные вопросы проектирования. Сокрытие информации хорошо - если информация не должна быть скрыта.
Скорость доступа: никакое различие.
Я ожидал бы, что любое различие прибудет из упаковки (для пространства) и кэширование (для скорости) проблемы. Оба они могли также явиться результатом примерно чего-либо еще также.
Трудно предположить или оценить. Это, вероятно, заняло бы время, но я сделаю демонстрационный проект и протестирую на скорость. Тестирование и скорость доступа и пространство с циклом. Протестируйте демонстрационный проект с эмулятором для той архитектуры.
Нет никакого различия в ENV, который Вы описываете когда дело доходит до пространства. Статический или глобальный var использует просто тот же объем памяти.
Для соображений скорости (но не хорошая практика) Вы могли предпочесть глобальный Вар при необходимости в доступе к var вне одного файла. (касательно использования external char my_global_char_placed_else_where;)
Для лучшей практики Вы используете, добираются/функции множества вместо этого, но они медленнее. Таким образом Вы могли использовать макросы для, получают/устанавливают var, который глобален для сокрытия от читателя кода, что var на самом деле глобален, но это - kind'a как обман. Но это может сделать код более читаемым.
Если Вы сравниваете сокрытие var в функции, то оно не имеет никакого различия по сравнению с размещением его вне функции, и больше функций могло иметь доступ к var.
Я сам использую MSP430, ARM7 (только для тестов) и AVR32 micros для разработки
То, что говорит Jonathan, не точно корректно. И статические и глобальные переменные будут (должен быть), сохраненный в ZI (или данные RW) регионы. Наклон компилятора "сохраняет" его по регистру строго - что это могло бы сделать, загрузить значение в регистр, использовать тот регистр для всех операций и, чем сохраняют то значение назад - это - компилятор определенная оптимизация. И даже затем, нет никакой причины, почему привычка компилятора делает это также для глобальных переменных: если, конечно, u не делают это энергозависимым. Но затем, технически можно также сделать статическую переменную энергозависимой, поэтому снова никакое различие.
Редактирование: о, да - пространство: никакое различие.