Используя различные типы числовой переменной

Я являюсь все еще довольно новым, так терпите меня на этом, мой вопрос (вопросы) не предназначены, чтобы быть спорным или мелким, но во время некоторого чтения чего-то показался мне нечетный.

Я нахожусь под предположением, что, когда компьютеры были медленными и память была дорогим использованием корректного типа переменной, было намного больше необходимости, чем это сегодня. Теперь, когда память немного легче прибыть людьми, кажется, ослабились немного. Например, Вы видите этот пример кода везде:

for (int i = 0; i < length; i++)

интервал? (-2 147 483 648 к 2,147,483,648) для длины? Разве байт не (0-255) лучший выбор?

Таким образом, мне любопытно из Вашего мнения и чему Вы верите, чтобы быть лучшей практикой, я очень не хочу думать, что это использовалось бы только потому, что акроним "интервал" более интуитивен для новичка..., или память только что стала столь дешевой, что мы действительно не должны интересоваться такими мелкими вещами, и поэтому мы должны просто использовать долго, таким образом, мы можем быть уверены, что какие-либо другие числа/типы (в причине) используемый могут быть брошены автоволшебно?

... или я, просто глупо касающимся сам такими вещами?

14
задан Leroy Jenkins 16 March 2010 в 04:00
поделиться

6 ответов

Luca Bolognese опубликовал это в своем блоге.

Вот соответствующая часть:

  • Используйте int везде, где ваши значения могут поместиться в int, даже для значений, которые никогда не могут быть отрицательными
  • Используйте long, когда ваши значения не могут поместиться в int.
  • Byte, sbyte, short, ushort, uint и ulong следует использовать только для взаимодействия с кодом на Си. В противном случае они не стоят того, чтобы с ними возиться.
10
ответ дан 1 December 2019 в 09:32
поделиться

Использование переменной, которая меньше, чем размер встроенного регистра процессора, может привести к тому, что будет выдаваться больше кода.

Как сказал другой автор, не беспокойтесь о микрооптимизации. Если у вас проблема с производительностью, сначала профилируйте. В 9 случаях из 10 проблема производительности окажется не там, где вы думали.

9
ответ дан 1 December 2019 в 09:32
поделиться

Вообще память в наше время дешева, так как вам не нужно беспокоиться о ней, вы можете заняться более важными деталями программирования. Думайте об этом как об управлении памятью, чем меньше вам приходится это делать, тем более продуктивно вы работаете в целом. В конечном итоге это связано с уровнем абстракции, если вам не нужно контролировать работу всех шестеренок и колесиков, то лучше не возиться с ними.

На практике вы, как правило, всегда будете использовать либо ints, либо longs (если вам нужен дополнительный размер). В наши дни я бы не стал беспокоиться о чем-то меньшем, если бы не занимался оптимизацией. И помните золотое правило оптимизации Не оптимизируйте, если это не нужно. Сначала напишите код, а потом оптимизируйте, если потребуется.

Другая похожая ситуация возникает при проектировании схемы базы данных. Я часто вижу, как люди разрабатывают схему, разрешая только то, что им нужно для столбцов NVARCHAR. На мой взгляд, это нелепо, потому что это столбец переменной длины, так что вы не тратите место впустую, а предоставив себе достаточно места, вы избежите проблем в будущем. Однажды я работал в компании, которая вела внутренний журнал на сайте; как только я перешел на IE8, сайт начал падать. После некоторого расследования я обнаружил, что схема ведения журнала допускает только 32 символа для строки идентификатора браузера, но при использовании IE8 (с Vis Studio и другими расширениями) строка идентификатора браузера превышала 32 и вызывала проблему, из-за которой сайт вообще не работал. Конечно, можно было бы сделать более строгую проверку длины и более эффективную обработку ошибок со стороны разработчика, отвечающего за это, но разрешение 256 вместо 32 не только предотвратило бы крах, но и не усекало бы данные в базе данных.

Я не предлагаю вам использовать строки и Int64 для всех ваших типов данных (не больше, чем я предлагаю вам установить все ваши sql-колонки в NVARCHAR(4000)), потому что вы потеряете читабельность. Но выберите подходящий тип и обеспечьте себе большой запас.

2
ответ дан 1 December 2019 в 09:32
поделиться

Локальные переменные, такие как индексы цикла, дешевы. Сколько кадров вы собираетесь иметь в стеке одновременно? Пятьдесят? Сотня? Тысяча? Каковы накладные расходы при использовании счетчиков тысяч int вместо счетчиков тысяч байтов ? 3К? Стоит ли переделывать экономию 3K, когда выясняется, что для пары из этих массивов требуется более 255 элементов?

Если вы выделяете десятки миллионов таких вещей, то уменьшение количества бит может иметь смысл. Для местных это ложная экономия.

Другой фактор - это то, что тип сообщения сообщает вашим читателям. Хорошо это или плохо, но люди очень мало интерпретируют int ; но когда они видят байт , они склонны интерпретировать его как нечто специфически ориентированное на байты, например двоичные данные, исходящие из потока, возможно, пиксели или поток, который необходимо запустить через кодировщик, чтобы превратить его в строку. Использование байта в качестве счетчика циклов сбивает с толку многих читателей вашего кода, поскольку они останавливаются и задаются вопросом: «Подождите, а почему это байт, а не int?»

2
ответ дан 1 December 2019 в 09:32
поделиться

Нет, я не думаю, что вы глупы, это отличный вопрос!

Я считаю, что использование сильно типизированных переменных - это лучшая практика. В вашем примере переменная i всегда положительна, поэтому она могла бы быть unsigned int.

При разработке программ необходимо учитывать: 1) размер 2) скорость и 3) затраты программиста. Они не являются взаимоисключающими, иногда мы идем на компромисс между размером и скоростью, и, конечно, те, кто лучше всего способен это сделать (великие программисты), стоят дороже, чем начинающие.

Также помните, что самое быстрое на компьютере X может быть медленнее на компьютере B. Это 16-битная, 32-битная, 64-битная и т.д. операционная система? Во многих случаях мы хотим, чтобы переменная была выровнена по границам слов для скорости, так что использование переменных размером меньше слова в итоге не экономит места.

Поэтому не обязательно лучше использовать самую маленькую возможную переменную, но всегда лучше сделать осознанный выбор, какой тип лучше использовать.

3
ответ дан 1 December 2019 в 09:32
поделиться

Рассмотрение этой заметки может помочь вам:

Время выполнения оптимизирует производительность 32-битных целочисленных типов (Int32 и UInt32), поэтому используйте эти типы для счетчиков и других часто используемых интегральных переменных. Для операций с плавающей точкой операций с плавающей точкой, Double является наиболее эффективным типом, потому что эти операции оптимизированы аппаратными средствами.

источник: MCTS Self-Paced Training Kit (Exam 70-536): Microsoft® .NET Framework Application Development Foundation, Second edition

Примечание: я думаю, что это нормально для машин x86, но для x64 я не знаю.

2
ответ дан 1 December 2019 в 09:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: