Целое число.NET по сравнению с Int16?

В Java все находится в форме класса.

Если вы хотите использовать любой объект, тогда у вас есть две фазы:

  1. Объявить
  2. Инициализация

Пример:

  • Объявление: Object a;
  • Инициализация: a=new Object();

То же самое для концепции массива

  • Объявление: Item i[]=new Item[5];
  • Инициализация: i[0]=new Item();

Если вы не дают секцию инициализации, тогда возникает NullpointerException.

50
задан gotqn 30 June 2015 в 20:33
поделиться

10 ответов

Согласно ниже ссылки, время выполнения оптимизирует производительность [1 113] Int32 и рекомендует им для счетчиков и других операций, к которым часто получают доступ.

Из книги: Рассчитанный на индивидуальную скорость обучения Учебный Набор MCTS (Экзамен 70-536): MicrosoftВ®.NET Framework 2.0— Основа Разработки приложений

Глава 1: "Основные принципы платформы"
Урок 1: "Используя Типы Значения"

Лучшие практики: Оптимизация производительности со встроенными типами

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

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

кроме того, Таблица 1-1 в тех же списках раздела рекомендовала использование для каждого типа. Относящийся к этому обсуждению:

  • Int16 - Взаимодействие и другое специализированное использование
  • Int32 - Целые числа и счетчики
  • Int64 - Большие целые числа
52
ответ дан hurst 7 November 2019 в 10:30
поделиться

Вы должны почти всегда использование Int32 или Int64 (и, нет, Вы не получаете кредит при помощи UInt32 или UInt64), когда цикличное выполнение по массиву или набору индексом.

самая очевидная причина, что это менее эффективно, состоит в том, что весь массив и индексы набора, найденные в BCL, берут Int32 с, таким образом, неявный бросок всегда попытка произойти в коде, который пытается использовать Int16 с в качестве индекса.

менее - очевидная причина (и причина, что массивы берут Int32 в качестве индекса) состоят в том, что спецификация CIL говорит, что все значения операционного стека или Int32 или Int64. Каждый раз Вы или загружаете или храните значение к любому другому целому типу (Byte, SByte, UInt16, Int16, UInt32, или UInt64), существует неявная включенная операция преобразования. Неподписанные типы не имеют никакого штрафа за загрузку, но за хранение значения, это составляет усечение и возможную проверку переполнения. Для типов со знаком каждый знак загрузки - расширяется, и каждое хранилище коллапсы знака (и имеет возможную проверку переполнения).

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

for (short i = 0; i < 32000; i++) {
    ...
}

хорошие Взгляды, правильно? Нет! Можно в основном проигнорировать инициализацию (short i = 0), так как это только происходит однажды, но сравнение (i<32000) и постепенное увеличение (i++) части происходит 32000 раз. Вот некоторый pesudo-код для того, на что эта вещь похожа на уровне машины:

  Int16 i = 0;
LOOP:
  Int32 temp0 = Convert_I16_To_I32(i); // !!!
  if (temp0 >= 32000) goto END;
  ...
  Int32 temp1 = Convert_I16_To_I32(i); // !!!
  Int32 temp2 = temp1 + 1;
  i = Convert_I32_To_I16(temp2); // !!!
  goto LOOP;
END:

существуют 3 преобразования там, которые выполняются 32000 времена. И их, возможно, полностью избежали, просто используя Int32 или Int64.

Обновление: Как я сказал в комментарии, я теперь, на самом деле записал сообщение в блоге по этой теме, Типы данных Интеграла.NET И Вы

84
ответ дан Alex Lyman 7 November 2019 в 10:30
поделиться

Int16 может на самом деле быть меньше эффективен, потому что x86 инструкции для доступа слова занимают больше места, чем инструкции для dword доступа. Это будет зависеть от того, что делает JIT. Но неважно, что, это почти наверняка не [еще 111] эффективный, когда используется в качестве переменной в повторении.

11
ответ дан Curt Hagenlocher 7 November 2019 в 10:30
поделиться

Противоположное верно.

32 (или 64) разрядные целые числа быстрее, чем int16. В целом собственный тип данных является самым быстрым.

Int16 хороши, если Вы хотите сделать свои структуры данных максимально минимизированными. Это оставляет свободное место и может улучшить производительность.

9
ответ дан Nils Pipenbrinck 7 November 2019 в 10:30
поделиться

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

Это могло бы иметь смысл с точки зрения устройства хранения данных, если Вы имеете очень ограниченные ресурсы - встроенные системы с крошечным стеком, соединяете проводом протоколы, разработанные для медленных сетей (например, GPRS и т.д.) и так далее.

3
ответ дан Russ 7 November 2019 в 10:30
поделиться

Никогда не принимайте эффективность.

то, Что или не более эффективно, будет варьироваться от компилятора до компилятора и платформы на платформу. Если Вы на самом деле не протестировали это, нет никакого способа сказать или int16, или интервал более эффективен.

я просто придерживался бы ints, если Вы не сталкиваетесь с доказанной проблемой производительности, которую решает использование int16.

2
ответ дан 17 of 26 7 November 2019 в 10:30
поделиться

Используйте Int32 на 32-разрядных машинах (или Int64 на 64-разрядных машинах) для самой быстрой производительности. Используйте меньший целый тип, если Вы действительно обеспокоены пространством, оно поднимает (может быть медленнее, хотя).

2
ответ дан Mark Cidade 7 November 2019 в 10:30
поделиться

Другие здесь корректны, только используют [меньше чем 110] Int32 (для 32-разрядного кода)/Int64 (для 64-разрядного кода), если Вам нужен он для экстремальных требований устройства хранения данных, или для другого уровня осуществления на поле бизнес-объекта (у Вас должна все еще быть propery проверка уровня в этом случае, конечно).

И в целом, не волнуйтесь об эффективности, пока не будет проблема производительности. И в этом случае, профиль это. И если предположение & при сверении с обоими путями, в то время как профилирование не помогает Вам достаточно, проверьте код IL.

Хороший вопрос все же. Вы узнаете больше, как компилятор делает это - вещь. Если Вы хотите учиться программировать более эффективно, изучая основы IL и как компиляторы C#/VB делают их задание было бы прекрасной идеей.

1
ответ дан Jon Adams 7 November 2019 в 10:30
поделиться

Я не могу предположить там быть любым значительным увеличением производительности на Int16 по сравнению с интервалом

, Вы сохраняете некоторые биты в объявлении переменной.

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

0
ответ дан Dana 7 November 2019 в 10:30
поделиться

Нет никакого значительного увеличения производительности в использовании типа данных, меньшего, чем Int32, на самом деле, я считал где-нибудь, что использование Int32 будет быстрее, чем Int16 из-за выделения памяти

0
ответ дан Leon Tayson 7 November 2019 в 10:30
поделиться