iBase.ru Forum

Вопрос опытным (все что ниже ИМХО, прошу поправить, для этого и пишу сюда)
Насколько знаю "внутри проца" в 32-разрядных системах происходит выравнивание переменных до 32 бит (ИМХО). По крайней мере два одинаковых алгоритма, которые экономят память используя переменные ShortInt, Byte, Char и Boolean работают медленнее чем соответственно Integer,Integer,Integer и Integer. Причем это сам обнаруживал на практике - Integer быстрее, чем замена его на ShortInt или Word.
Собственно вопрос: использование в таблице FB/IB полей ShortInt, Char(1) вместо соответственно Integer, Integer приведет к экономии размера БД, но и уменьшению производительности - это верно? Имеются ввиду базы в десятки гигабайт, причем производительность приоритетна и если использование Integer вместо Char(1) приведет хотя бы к 1% увеличения производительности - для меня это серьезная причина не экономить дисковое пространство.

Эти рассуждения неверны, так что, нет, не приведёт.

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

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

Так что кажется мне что обещанных в статье 8-10% между INTEGER и SMALLINT сейчас не будет.

Это ж легко самому проверить.
Я вот только что на 2.1 на Core2Duo E6420 2Gb RAM 160 HDD 7200 WD проверил, на 10 млн. записях:

IBExpert писал(а):SELECT COUNT(C1) FROM TT WHERE C1 = 0
15.20

SELECT COUNT(C1) FROM TT WHERE C1 = '0'
2.30

SELECT COUNT(I) FROM TT WHERE I = 0
2.05

SELECT COUNT(S) FROM TT WHERE S = 0
2.11

SELECT C1, COUNT(C1) FROM TT GROUP BY C1 ORDER BY C1
33.10

SELECT I, COUNT(I) FROM TT GROUP BY I ORDER BY I
28.44

SELECT S, COUNT(S) FROM TT GROUP BY S ORDER BY S
27.50

SELECT COUNT(C1) FROM TT WHERE C1 = 0 OR C1 = 1
21.79

SELECT COUNT(C1) FROM TT WHERE C1 = '0' OR C1 = '1'
4.35

SELECT COUNT(I) FROM TT WHERE I = 0 OR I = 1
3.58

SELECT COUNT(S) FROM TT WHERE S = 0 OR S = 1
3.58

Замечу только, что сравнение C1 с целочисленным значением выдавало план NATURAL. Остальное и так видно.

Хм. Т.е. я был прав. Из выводов в статье "2. Разницы в объеме занимаемых данных между char(1), integer и smallint нет как для таблиц, так и для индексов." - смысла нет делать SmallInt или Char(1) - объем БД не изменится. А вот скорострельность, и внутри птички и в алгоритмах на стороне клиента будет быстрее при использовании 32-х разрядных переменных на, соответственно, 32-х разрядных системах.

WildSery спасиба.

ps Интересно, для 64-х разрядных систем будет тоже самое?

На 64-х разрядных системах думаю будет тоже самое, процу придеться всеравно таскать банки памяти и колоть их по 64 бита и сразу обрабатывать - это быстрее чем маскировать, колоть или дополнять в регистрах до этих 64 бит.

Таки в чём выигрыш?
В первом случае small > int на 2%
Во втором small < int на 3%
В третьем - одинаково...

В пределах погрешности, в общем, равны.
Медленнее только CHAR(1).