Данная книга задумана как методическое пособие для подготовки к экзамену BSDA. Книга, тем не менее, может быть полезна не только тем кто собирается сдавать этот экзамен, но и просто широкому кругу IT-специалистов, желающих систематизировать свои знания об операционных системах семейства BSD (NetBSD, OpenBSD, FreeBSD, DragonFly BSD).
Читать -> BSDA в вопросах и ответах
Материал написан Евгением Миньковским, он старый, но многое актуально для понятия основ и по сей день.
Перевод статьи «Getting Familiar with GCC Parameters», автор — Mulyadi Santosa
gcc (GNU C Compiler) — набор утилит для компиляции, ассемблирования и компоновки. Их целью является создание готового к запуску исполняемого файла в формате, понимаемом вашей ОС. Для Linux, этим форматом является ELF (Executable and Linking Format) на x86 (32- и 64-битных). Но знаете ли вы, что могут сделать для вас некоторые параметры gcc? Если вы ищете способы оптимизации получаемого бинарного файла, подготовки сессии отладки или просто наблюдать за действиями, предпринимаемыми gcc для превращения вашего исходного кода в исполняемый файл, то знакомство с этими параметрами обязательно. Так что, читайте.
Напомню, что gcc делает несколько шагов, а не только один. Вот небольшое объяснение их смысла:
— Препроцессирование: Создание кода, более не содержащего директив. Вещи вроде «#if» не могут быть поняты компилятором, поэтому должны быть переведены в реальный код. Также на этой стадии разворачиваются макросы, делая итоговый код больше, чем оригинальный. [1]
— Компиляция: Берется обработанный код, проводятся лексический и синтаксический анализы, и генерируется ассемблерный код. В течение этой фазы, gcc выдает сообщения об ошибках или предупреждениях в случае, если анализатор при парсинге вашего кода находит там какие-либо ошибки. Если запрашивается оптимизация, gcc продолжит анализировать ваш код в поисках улучшений и манипулировать с ними дальнейшем. Эта работа происходит в многопроходном стиле, что показывает то, что иногда требуется больше одного прохода по коду для оптимизации. [2]
— Ассемблирование: Принимаются ассемблерные мнемоники и производятся объектные коды, содержащие коды команд. Часто недопонимают то, что на стадии компиляции не производятся коды команд, это делается на стадии ассемблирования. В результате получаются один или более объектных файла, содержащие коды команд, которые являются действительно машинозависимыми. [3]
— Компоновка: Трансформирует объектные файлы в итоговые исполняемые. Одних только кодов операции недостаточно для того, чтобы операционная система распознала и выполнила их. Они должны быть встроены в более полную форму. Эта форма, известная как бинарный формат, указывает, как ОС загружает бинарный файл, компонует перемещение и делает другую необходимую работу. ELF является форматом по умолчанию для Linux на x86. [4]
Параметры gcc описаны здесь, прямо и косвенно затрагивая все четыре стадии, поэтому для ясности, эта статья построена следующим образом:
— Параметры, относящиеся к оптимизации
— Параметры, относящиеся к вызову функций
— Параметры, относящиеся к отладке
— Параметры, относящиеся к препроцессированию
Прежде всего, давайте ознакомимся с вспомогательными инструментами, которые помогут нам проникать в итоговый код:
— Коллекция утилит ELF, которая включает в себя такие программы, как objdump и readelf. Они парсят для нас информацию о ELF.
— Oprofile, один из стандартных путей подсчета производительности аппаратного обеспечения. Нам нужна эта утилита для просмотра нескольких аспектов производительности кода.
— time, простой способ узнать общее время работы программы.
Следующие инструкции могут быть применены в gcc версий 3.x и 4.x, так что они достаточно общие. Начнем копать?
.
gcc предоставляет очень простой способ производить оптимизацию: опция -O. Она и ускоряет выполнение вашего кода, и сжимает размер итогового кода. У неё существует пять вариантов:
— от -O0 (O ноль) до -O3. «0» означает отсутствие оптимизации, а «3» — наивысший уровень оптимизации. «1» и «2» находятся между этими краями. Если просто используете -O без указания номера, это будет означать -O1.
— -Os говорит gcc оптимизировать размер. В общем-то, это похоже на -O2, но пропускает несколько шагов, которые могут увеличить размер.
Какое ускорение в действительности можно от них получить? Что ж, предположим, у нас есть такой код:
#include int main(int argc, char *argv[]) { int i,j,k; unsigned long acc=0; for(i=0;i<10000;i++) for(j=0;j<5000;j++) for(k=0;k<4;k++) acc+=k; printf("acc = %lun",acc); return 0; }
С помощью gcc, создадутся четыре разных бинарных файла, используя каждый из -O вариантов (кроме -Os). Утилита time запишет их время исполнения, таким образом:
$ time ./non-optimized
| Без оптимизации | -O1 | -O2 | -O3 | |
| real | 0.728 | 0.1 | 0.1 | 0.1 |
| user | 0.728 | 0.097 | 0.1 | 0.1 |
| sys | 0.000 | 0.002 | 0.000 | 0.000 |
Для упрощения, будем использовать следующие обозначения:
— Non-optimized обозначает исполняемый файл, скомпилированный с опцией -O0.
— OptimizedO1 обозначает исполняемый файл, скомпилированный с опцией -O1.
— OptimizedO2 обозначает исполняемый файл, скомпилированный с опцией -O2.
— OptimizedO3 обозначает исполняемый файл, скомпилированный с опцией -O3.
Как вы могли заметить, время выполнения программы, скомпилированной с -O1 в семь раз меньше, чем время выполнения программы, при компиляции которой не использовалась оптимизация. Обратите внимание, что нет большой разницы между -O1, -O2 и -O3, — на самом деле, они почти одинаковы. Так в чем же магия -O1?
После беглого изучения исходного кода, вы должны отметить, что такой код конечен для оптимизации. Прежде всего, давайте посмотрим на короткое сравнение дизассемблированных версий non-optimized и optimizedO1:
$ objdump -D non-optimized $ objdump -D optimizedO1
(Примечание: вы можете получить другие результаты, поэтому используйте эти как основные)
| Non-optimized | OptimizedO1 |
| mov 0xfffffff4(%ebp)
add %eax,0xfffffff8(%ebp) addl $0x1,0xfffffff4(%ebp) cmpl $0x3,0xfffffff4(%ebp) |
add $0x6,%edx
add $0x1,%eax cmp $0x1388,%eax |
Приведенные примеры реализуют самый вложенный цикл (for (k=0;k<4;k++)). Обратите внимание на различие: неоптимизированный код напрямую загружает и хранит из адреса памяти, в то время как optimized01 использует регистры ЦПУ в качестве сумматора и счетчик цикла. Как вам, возможно, известно, доступ к регистрам может быть получен в сотни или тысячи раз быстрее, чем к ячейкам ОЗУ.
Не удовлетворяясь простым использованием регистров ЦПУ, gcc использует другой трюк оптимизации. Давайте снова посмотрим дизассемблированный код optimizedO1 и обратим внимание на функцию main():
...... 08048390 : ... 80483a1: b9 00 00 00 00 mov $0x0,%ecx 80483a6: eb 1f jmp 80483c7 80483a8: 81 c1 30 75 00 00 add $0x7530,%ecx
0x7530 это 30000 в десятичной форме, поэтому мы можем быстро угадать цикл. Этот код представляет собой самый вложенный и самый внешний циклы (for(j=0;j<5000;j++) … for(k=0;k<4;k++)), так как они являются буквальным запросом на 30000 проходов. Примите во внимание, что вам нужно всего лишь три прохода внутри. Когда k=0, acc остается прежним, поэтому первый проход можно проигнорировать.
80483ae: 81 f9 00 a3 e1 11 cmp $0x11e1a300,%ecx 80483b4: 74 1a je 80483d0 80483b6: eb 0f jmp 80483c7
Хмм, теперь это соответствует 300 000 000 (10 000*5 000*6). Представлены все три цикла. После достижения этого числа проходов, мы переходим прямо к printf() для вывода суммы (адреса 0x80483d0 — 0x80483db).
80483b8: 83 c2 06 add $0x6,%edx 80483bb: 83 c0 01 add $0x1,%eax 80483be: 3d 88 13 00 00 cmp $0x1388,%eax 80483c3: 74 e3 je 80483a8 80483c5: eb f1 jmp 80483b8
Шесть добавляется в сумматор при каждой итерации. В итоге, %edx будет содержать всю сумму после выполнения всех трех циклов. Третья и четвертая строки показывают нам, что после выполнения 5000 раз, должен быть переход к адресу 0x80483a8 (как указано ранее).
Мы можем заключить, что gcc создает здесь упрощение. Вместо прохода три раза в самый вложенный цикл, он просто добавляет шесть для каждого среднего цикла. Это звучит просто, но это заставляет вашу программу сделать только 100 000 000 проходов вместо 300 000 000. Это упрощение, называемое разворачиванием цикла, одно из тех задач, которые делают -O1/2/3. Конечно же, вы и сами можете это сделать, но иногда неплохо знать, что gcc может определить такие вещи и оптимизировать их.
С опциями -O2 и -O3 gcc тоже пытается произвести оптимизацию. Обычно она достигается посредством переупорядочивания [5] и трансформацией кода. Целью этой процедуры является устранить столько ошибочных ветвей, сколько возможно, что повышает качество использования конвейера. Например, мы можем сравнить, как non-optimized и optimizedO2 выполняет самый внешний цикл.
80483d4: 83 45 ec 01 addl $0x1,0xffffffec(%ebp) 80483d8: 81 7d ec 0f 27 00 00 cmpl $0x270f,0xffffffec(%ebp) 80483df: 7e c4 jle 80483a5
Бинарный файл non-optimized использует jle для выполнения перехода. Математически это означает, что вероятность выбора ветви 50%. С другой стороны, версия optimizedO2 использует следующее:
80483b4: 81 c1 30 75 00 00 add $0x7530,%ecx 80483ba: 81 f9 00 a3 e1 11 cmp $0x11e1a300,%ecx 80483c0: 75 e1 jne 80483a3
Теперь, вместо jle используется jne. При условии, что любое целое может быть сопоставлено в предыдущем cmp, нетрудно сделать вывод, что это увеличит шанс выбора ветви почти до 100%. Это небольшое, но полезное указание процессору для определения того, какой код должен быть выполнен. Хотя, для большинства современных процессоров, этот вид трансформации не является ужасно необходимым, так как предсказатель переходов достаточно умен для того, чтобы сделать это сам.
Для доказательства того, как сильно это изменение может помощь, к нам на помощь придет OProfile. Oprofile выполнен для записи числа изолированных ветвей и изолированных ошибочных ветвей. Изолированные здесь обозначает «выполненные внутри конвейера данных ЦПУ»
$ opcontrol --event=RETIRED_BRANCHES_MISPREDICTED:1000 --event=RETIRED_BRANCHES:1000;
Мы запустим non-optimized и optimizedO2 пять раз каждый. Затем мы возьмем максимум и минимум примеров. Мы посчитаем степень ошибки, используя эту формулу (выведена отсюда).
Степень ошибки = изолированные ошибочные ветви / изолированные ветви
Теперь вычислим степень ошибки для каждого бинарного файла. Для non-optimized получилось 0,5117%, в то время как optimizedO2 получил 0,4323% — в нашем случае, выгода очень мала. Фактическая выгода может различаться для реальных случаев, так как gcc сам по себе не может много сделать без внешних указаний. Пожалуйста, прочтите о __builtin_expect() в документации по gcc для подробной информации.
По существу, gcc предоставляет вам несколько путей управления тем, как вызывается функция. Сначала давайте рассмотрим встраивание. С помощью встраивания, вы сокращаете стоимость вызова функции, так как тело функции подставлено прямо в вызывающую функцию. Пожалуйста, учтите, что это не по умолчанию, а только когда вы используете -O3 или, по крайней мере, -finline-functions.
Как полученный бинарный файл выглядит после того, как gcc сделает встраивание? Рассмотрим следующий листинг:
#include inline test(int a, int b, int c) { int d; d=a*b*c; printf("%d * %d * %d is %dn",a,b,c,d); } static inline test2(int a, int b, int c) { int d; d=a+b+c; printf("%d + %d + %d is %dn",a,b,c,d); } int main(int argc, char *argv[]) { test(1,2,3); test2(4,5,6); }
Скомпилируем этот код со следующим параметром:
$ gcc -S -O3 -o
-S указывает gcc остановиться сразу после стадии компиляции (мы расскажем о ней позже в этой статье). Результат будет следующим:
.... test: pushl %ebp movl %esp, %ebp pushl %ebx .... main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) ... movl $6, 16(%esp) movl $3, 12(%esp) movl $2, 8(%esp) movl $1, 4(%esp) movl $.LC0, (%esp) call printf ... movl $15, 16(%esp) movl $6, 12(%esp) movl $5, 8(%esp) movl $4, 4(%esp) movl $.LC1, (%esp) call printf ...
И test(), и test() действительно встроены, но вы также можете видеть test(), который остался вне main(). Вот где играет роль ключевое слово static. Написав, что функция — static, вы сообщаете gcc, что эта функция не будет вызываться из какого-либо внешнего объектного файла, поэтому нет нужды порождать коды. Таким образом, это экономит размер, и если вы можете сделать функцию статичной, сделайте это где только возможно. С другой стороны, будьте благоразумны при решении, какая функция должна быть встраиваемой. Увеличение размера для небольшого увеличения скорости не всегда оправдано.
С помощью некоторой эвристики, gcc решает, должна быть функция встраиваемой, или нет. Одним из таких доводов является размер функции в терминах псевдо-инструкций. По умолчанию, лимитом является 600. Вы можете поменять этот лимит, используя -finline-limit. Проэксперементируйте для нахождения лучших лимитов встраивания для вашего конкретного случая. Также возможно переделать эвристику так, чтобы gcc всегда встраивал функцию. Просто объявите вашу функцию так:
__attribute__((always_inline)) static inline test(int a, int b, int c)
Теперь перейдем к передаче параметров. На архитектуре x86, параметры помещаются в стек и позже достаются из стека для дальнейшей обработки. Но gcc дает вам возможность изменить это поведение и использовать вместо этого регистры. Функции, у которых меньше трех параметров могут использовать эту возможность указанием -mregparm=, где n — число регистров, которое вы хотите использовать. Если мы применим этот параметр (n=3) к предыдущему коду, убрав атрибут inline и не используя оптимизацию, мы получим:
... test: pushl %ebp movl %esp, %ebp subl $56, %esp movl %eax, -20(%ebp) movl %edx, -24(%ebp) movl %ecx, -28(%ebp) ... main: ... movl $3, %ecx movl $2, %edx movl $1, %eax call test
Вместо стека, используются EAX, EDX и ECX для хранения первого, второго и третьего параметров. Поскольку доступ к регистру происходит быстрее, чем к ОЗУ, это будет одним из способов уменьшить время работы. Хотя вы должны обратить внимание на следующие вещи:
— Вы ДОЛЖНЫ компилировать весь ваш код с таким же числом -mregparm регистров. Иначе у вас будут проблемы с вызовом функций из другого объектного файла, если они будут принимать разные соглашения.
— Используя -mregparm, вы разрушаете совместимый с Intel x86 бинарный интерфейс приложений (ABI). Поэтому, вы должны учитывать это, если вы распространяете свое ПО только в бинарной форме.
Возможно, вы заметили эту последовательность в начале каждой функции:
push %ebp mov %esp,%ebp sub $0x28,%esp
Эта последовательность, также известная как пролог функции, написана чтобы установить указатель фрейма (EBP). Это приносит пользу, помогая отладчику делать трассировку стека. Следующая структура поможет вам понять это [6]:
[ebp-01] Последний байт последней локальной переменной
[ebp+00] Старое значение ebp
[ebp+04] Возвращает адрес
[ebp+08] Первый аргумент
Можем мы пренебречь этим? Да, с помощью -fomit-frame-pointer, пролог будет укорочен, так что функция начнется просто с выделения стека (если есть локальные переменные):
sub $0x28,%esp
Если функция вызывается очень часто, вырезание пролога спасет несколько тактов ЦПУ. Но будьте осторожны: делая это, вы также усложняете отладчику задачу по изучению стека. Например, давайте добавим test(7,7,7) в конец test2() и перекомпилируем с параметром -fomit-frame-pointer и без оптимизации. Теперь запустите gdb для исследования бинарного файла:
$ gdb inline (gdb) break test (gdb) r Breakpoint 1, 0x08048384 in test () (gdb) cont Breakpoint 1, 0x08048384 in test () (gdb) bt #0 0x08048384 in test () #1 0x08048424 in test2 () #2 0x00000007 in ?? () #3 0x00000007 in ?? () #4 0x00000007 in ?? () #5 0x00000006 in ?? () #6 0x0000000f in ?? () #7 0x00000000 in ?? ()
При втором вызове test, программа остановилась, и gdb вывел трассировку стека. В нормальной ситуации, main() должна идти в фрейме №2, но мы видим только знаки вопроса. Запомните, что я сказал про расположение стека: отсутствие указателя фрейма мешает gdb находить расположение сохраненного возвращаемого адреса в фрейме №2.
Каждый иногда нуждается в отладке его или её кода. Когда это время приходит, обычно вы запускаете gdb, ставите точки останова там и тут, анализируете бэктрейсы, и так далее, чтобы выявить расположение нарушающего работу кода. А что получаете на самом деле? Если вы не используете опции отладки, вы просто получаете адрес, указывающий на регистр EIP.
Вот в чем проблема, в действительности вы не хотите адрес. Вы хотите, чтобы gdb или другой отладчик просто показал требуемые строки. Но gdb не может этого сделать без определенного вида помощи. Эта помощь, называемая отладкой с приписываемыми форматами записи (Debugging With Attributed Record Formats — DWARF), помогает вам выполнять отладку на уровне исходного кода.
Как это сделать? Используйте -g при компиляции в объектный код, то есть:
gcc -o -g test test.c
Что такого добавляет gcc, что отладчик может сопоставлять адрес с исходным кодом? Вам нужна dwarfdump [7] чтобы узнать это. Это утилита находится внутри тарболла libdwarf или в RPM, так что вы не найдете её в виде отдельного пакета. Скомпилируйте её сами или просто установите из репозитория вашего дистрибутива; оба варианта должны сработать. В этой части статьи я использую версию 20060614 RPM.
Используя readelf, вы можете отметить, что в неотлаженной версии первого листинга существует 28 разделов:
$ readelf -S ./non-optimized
Но в отлаженной версий есть 36 разделов. Новые разделы:
* debug_arranges
* debug_pubnames
* debug_info
* debug_abbrev
* debug_line
* debug_frame
* debug_str
* debug_loc
Вам не нужно копаться во всех этих разделах; для быстрого изучения, будет достаточно рассмотреть .debug_line. Команда, которая вам нужна:
$ /path/to/dwarfdump -l <object width="100" height="100" type="application/x-shockwave-flash"></object>
Вот пример того, что вы получите:
.debug_line: line number info for a single cu Source lines (from CU-DIE at .debug_info offset 11): [row,column] // /code/./non-optimized.c: [ 3,-1] 0x8048384 // new statement /code/./non-optimized.c: [ 5,-1] 0x8048395 // new statement ...............
Интерпретация этих сообщений довольно простая. Возьмите первую запись (идущую за строкой ) в качестве примера:
line number 3 in file non-optimized.c is located in address 0x8048384.
gdb дает ту же информацию:
$ gdb non-optimized-debugging (gdb) l *0x8048384 0x8048384 is in main (./non-optimized.c:3).
readelf также предоставляет похожую информацию, используя —debug-info:
$ readelf --debug-dump=line <object width="100" height="100" type="application/x-shockwave-flash"></object>
И readelf, и dwarfdump могут анализировать информацию отладки, так что вы вольны выбирать сами.
Что вы должны понимать, так это то, что исходный код сам по себе не встроен в объектный файл. На самом деле, отладчик должен проверять отдельный файл исходного кода. Запись в колонке помогает определять, откуда загружать файл исходного кода. Учтите, что она содержит полный путь, что значит невозможность его нахождения gdb в случае перемещения или переименования.
gcc сам имеет возможность давать много информации об отладке. Кроме DWARF, существуют:
* Stabs: -gstabs производит собственный формат stabs, в то время, как -gstabs+ включает в себя специфичные расширения GNU.
* Common Object File Format (COFF): Создается с помощью -gcoff.
* XCOFF: Создается с помощью -gxcoff. Если вы предпочитаете включать расширения GNU, используйте -gxcoff+.
* Virtual Memory System (VMS): Создается с помощью -gvms.
Каждый из этих форматов описаны в ссылках ([8], [9] и [10]), но для x86-совместимой архитектуры, без проблем, вам лучше использовать формат DWARF. Последней спецификацией DWARF является DWARF третьей версии, и gdb может создавать её с помощью -gdwarf-2. Это может ввести в заблуждение новых пользователей, так как вы можете подумать, что такая опция создаст информацию DWARF 2. На самом деле, DWARF 2 объединен с некоторыми возможностями DWARF 3. Не каждый отладчик поддерживает третью версию, поэтому используйте её с осторожностью.
Хотя не всегда все идет так гладко. Когда вы комбинируете опции -O и -g, для информации о строке необходимо установить связь с фактическим кодом в упомянутом сдвиге адреса. Пример может это пояснить. Возьмите файл (я снова использую первый листинг) и скомпилируйте его:
$ gcc -O2 -ggdb -o debug-optimized listing-one.c $ readelf --debug-dump=line debug-optimized .. Special opcode 107: advance Address by 7 to 0x80483aa and Line by 4 to 11 ...
Но что говорит gdb?
$ gdb debug-optimized (gdb) l *0x80483aa 0x80483aa is in main (./non-optimized.c:11). ... 11 printf("acc = %lun",acc); ... (gdb) disassemble main ... 0x080483aa : add $0x6,%edx 0x080483ad : cmp $0x1388,%eax ...
Здесь вы видите полное расхождение. Изучая одну информацию об отладке, вы будете ожидать, что указанный адрес содержит что-то вроде инструкции CALL. Но в действительности, вы получите инструкции ADD и CMP, что больше похоже на конструкцию цикла. Это побочный эффект действий оптимизации — в этом случае меняется порядок инструкций. Так что возьмите себе за правило не смешивать опции -g (или её варианты) c -O.
В целях изучения, иногда вы хотите узнать, как ваш исходный код трансформируется в исполняемый. К счастью, gcc предоставляет вам опции для остановки на любой стадии обработки. Вспомните, что gcc имеет несколько стадий завершения, — например, компоновку. Есть такие опции:
* -c останавливает на стадии ассемблирования, но пропускает компоновку. Результатом является объектный код.
* -E останавливает на стадии препроцессинга. Все директивы препроцессора развернуты, так что вы видите только чистый код.
* -S останавливает после компиляции. Она оставляет вас с ассемблерным кодом.
-c наиболее часто используется, когда у вас есть несколько исходных файлов и вы хотите скомбинировать их для получения итогового исполняемого файла. Так что, вместо такого:
$ gcc -o final-binary test1.c test2.c
будет лучше разделить их так:
$ gcc -c -o test1.o test1.c $ gcc -c -o test2.o test2.c
и затем:
$ gcc -o final-binary ./test1.o ./test1.o
Возможно, вы заметили, что такая же последовательность используется, если вы собираете программу, используя Makefile. Преимущество использования -c ясно: вам нужно перекомпилировать только измененные исходные файлы. Только фаза, на которой переделывается компоновка всех объектных файлов, и это очень экономит время, особенно в больших проектах. Очевидным примером этого является ядро Linux.
-E будет полезна, если вы хотите посмотреть, как ваш код в действительности выглядит после разворачивания макросов, определений и т.п. Возьмите следующий листинг в качестве примера:
#include #define A 2 #define B 4 #define calculate(a,b) a*a + b*b void plain_dummy() { printf("Just a dummyn"); } static inline justtest() { printf("Hi!n"); } int main(int argc, char *argv[]) { #ifdef TEST justtest(); #endif printf("%dn", calculate(A,B)); return 0; }
Скомпилируем его следующим образом:
$ gcc -E -o listing2.e listing2.c
Учтите, что мы не указываем параметров -D, что означает, что TEST не определен. Так и что мы имеем в препроцессорном файле?
void plain_dummy() { printf("Just a dummyn"); } static inline justtest() { printf("Hi!n"); } int main(int argc, char *argv[]) { printf("%dn", 2*2 + 4*4); return 0; }
А где вызов justtest() внутри main()? Нигде. TEST не определен — вот почему код исключен. Вы также можете видеть, что макрос calculate уже развернут в умножение и сложение констант. В конечной исполняемой форме, эти числа будут заменены результатами операций. Как вы видите, -E довольно удобна для проверки корректности директив.
Обратите внимание, что plain_dummy() все ещё здесь, не смотря на то, что она ни разу не вызывается. Это не удивительно, так как ещё не была произведена компиляция, вот почему не произошло исключение «мертвого» кода на этой стадии. stdio.h также развернут, но не показан в листинге выше.
Я нашел интересное приложение использования -E в качестве утилиты создания HTML. Вкратце, она помогает вам перенимать обычные действия в программировании, такие как модуляризация кода и макросы в мир HTML — то, что не может быть сделано на чистом HTML.
-S дает вам код на ассемблере, больше похожий на то, что вы видите с помощью objdump -d/-D. Хотя с помощью -S вы продолжите видеть директивы и имена символов, который делают код проще к изучению. Например, вызов printf(«%dn», 20) может быть трансформирован в:
.section .rodata.str1.1,"aMS",@progbits,1 .LC0: .string "%dn" ... movl $20, 4(%esp) movl $.LC0, (%esp) call printf
Вы можете видеть, что format string %d помещена в область данных, доступную только для чтения (.rodata). Также, вы можете удостовериться, что аргументы помещаются в стек справа налево, со строкой форматирования на верху стека.
gcc дает нам много полезных опций для превращения нашего кода во что угодно. Понимая, что эти опции делают на самом деле, мы можем сделать программу быстрее и ловчее. Хотя, не будьте целиком от них зависимы: вы должны больше внимания уделять написанию эффективного и хорошо структурированного кода.
Я хочу поблагодарить сообщества на irc каналах OFTC (#kernelnewbies и #gcc) и #osdev (Freenode) за их полезные идеи.
1. Статья в Википедии о Препроцессоре;
2. Статья в Википедии о Компиляторе;
3. Статья в Википедии об Ассемблере;
4. Статья в Википедии о Компоновщике.
5. Пример переупорядочивания кода (англ.);
6. Frame pointer omission (FPO) optimization and consequences when debugging, Часть 1 и Часть 2 (англ.);
7. Описание DWARF (англ.);
8. Описание stabs (англ.);
9. Описание COFF (англ.);
10. Описание XCOFF (варианта COFF) (англ.);
11. Использование препроцессора C в качестве утилиты создания HTML (англ.);
12. Документация по gcc (англ.);
13. AMD Athlon Processor x86 Code Optimization Guide (англ., pdf).
Установка модулей для Perl требуется для работы различных утилит, применяемх в повседневной рутине администрирования. Установка Perl модулей вручную с удоволетворением всех зависимостей это довольно скучный и нудный процесс.
Установка Perl модулей с испоьльзованием CPAN намного более лучшее решение, так как все зависимости определятся и установятся автоматически. В это статье я опишу оба метода установки модулей.
Когда какой-либо нужный модуль не установлен, приложение которое его использует будет показывать следующую ошибку. В данном случае отсутствует модуль XML:Parser.
<strong>Can’t locate</strong> XML/parser.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.10.0 .)
Download Perl module
Перейдите на веб-сайт CPAN Search и найдите модуль который вам нужно скачать. В этом пример мы скачаем и установим модуль XML:Parser Perl. Я скачаю XML-Parser-2.36.tar.gz в /home/download
$ cd /home/download $ gzip -d XML-Parser-2.36.tar.gz $ tar xvf XML-Parser-2.36.tar $ cd XML-Parser-2.36
$ perl Makefile.PL Checking if your kit is complete… Looks good Writing Makefile for XML:Parser::Expat Writing Makefile for XML:Parser $ make $ make test
$ make install
Это простой модуль без зависимостей, поэтому он установился без проблем. Обычно, любой модуль Perl имеет несколько зависимостей. Ставить все модули поочередно описанным выше методом скучнейшая задача. Я рекомендую использовать для установки CPAN метод, описанный ниже. Вручную стоит собирать модули в случае отсутсвия подключения к интернету.
Для установки Perl модулей используя CPAN, убедитесь что команда cpan работает. В этом примере, модуль CPAN ещё не установлен.
$ cpan -bash: cpan: command not found $ perl -MCPAN -e shell Can’t locate CPAN.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.10.0 .). BEGIN failed–compilation aborted.
$ yum install perl-CPAN
Результат работы команды:
Loaded plugins: refresh-packagekit updates-newkey | 2.3 kB 00:00 primary.sqlite.bz2 | 2.4 MB 00:00 Setting up Install Process Parsing package install arguments Resolving Dependencies Transaction Summary ============================================================================= Install 5 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 1.0 M Is this ok [y/N]: y Downloading Packages: (1/5): perl-ExtUtils-ParseXS-2.18-31.fc9.i386.rpm | 30 kB 00:00 (2/5): perl-Test-Harness-2.64-31.fc9.i386.rpm | 70 kB 00:00 (3/5): perl-CPAN-1.9205-31.fc9.i386.rpm | 217 kB 00:00 (4/5): perl-ExtUtils-MakeMaker-6.36-31.fc9.i386.rpm | 284 kB 00:00 (5/5): perl-devel-5.10.0-31.fc9.i386.rpm | 408 kB 00:00 Installing : perl-ExtUtils-ParseXS [1/5] Installing : perl-devel [2/5] Installing : perl-Test-Harness [3/5] Installing : perl-ExtUtils-MakeMaker [4/5] Installing : perl-CPAN [5/5] Installed: perl-CPAN.i386 0:1.9205-31.fc9 Dependency Installed: perl-ExtUtils-MakeMaker.i386 0:6.36-31.fc9 perl-ExtUtils-ParseXS.i386 1:2.18-31.fc9 perl-Test-Harness.i386 0:2.64-31.fc9 perl-devel.i386 4:5.10.0-31.fc9 Complete!
При первом вызове cpan вы должны указать некоторые конфигурационные параметры как показано ниже. Я покажу только важные параметры конфигурации. Значения по умолчанию принимаются нажатием клавиши enter.
$ cpan Sorry, we have to rerun the configuration dialog for CPAN.pm due to some missing parameters… CPAN build and cache directory? [/root/.cpan] Download target directory? [/root/.cpan/sources] Directory where the build process takes place? [/root/.cpan/build] Always commit changes to config variables to disk? [no] Cache size for build directory (in MB)? [100] Let the index expire after how many days? [1] Perform cache scanning (atstart or never)? [atstart] Cache metadata (yes/no)? [yes] Policy on building prerequisites (follow, ask or ignore)? [ask] Parameters for the ‘perl Makefile.PL’ command? [] Parameters for the ‘perl Build.PL’ command? [] Your ftp_proxy? [] Your http_proxy? [] Your no_proxy? [] Is it OK to try to connect to the Internet? [yes] First, pick a nearby continent and country by typing in the number(s) (1) Africa (2) Asia (3) Central America (4) Europe (5) North America (6) Oceania (7) South America Select your continent (or several nearby continents) [] 5 (1) Bahamas (2) Canada (3) Mexico (4) United States Select your country (or several nearby countries) [] 4 (2) ftp://carroll.cac.psu.edu/pub/CPAN/ (3) ftp://cpan-du.viaverio.com/pub/CPAN/ (4) ftp://cpan-sj.viaverio.com/pub/CPAN/ (5) ftp://cpan.calvin.edu/pub/CPAN (6) ftp://cpan.cs.utah.edu/pub/CPAN/ e.g. ‘1 4 5′ or ‘7 1-4 8′ [] 2-16 cpan[1]> o conf commit commit: wrote ‘/usr/lib/perl5/5.10.0/CPAN/Config.pm’ cpan[2]> quit No history written (no histfile specified). Lockfile removed.
Вы можете использовать один из указанных тут методов для установки новых модулей:
$ /usr/bin/perl -MCPAN -e ‘install Email::Reply’ (или) $ cpan cpan shell — CPAN exploration and modules installation (v1.9205) ReadLine support available (maybe install Bundle::CPAN or Bundle::CPANxxl?) cpan[1]> install “Email::Reply”;
В результате выполнения команды вы увидите
CPAN: Storable loaded ok (v2.18) Going to read /root/.cpan/Metadata Database was generated on Mon, 15 Sep 2008 11:02:52 GMT Running install for module 'Email::Reply' Running make for R/RJ/RJBS/Email-Reply-1.202.tar.gz CPAN: LWP::UserAgent loaded ok (v2.036) CPAN: Time::HiRes loaded ok (v1.9711) Fetching with LWP: ftp://carroll.cac.psu.edu/pub/CPAN/authors/id/R/RJ/RJBS/Email-Reply-1.202.tar.gz CPAN: checksum security checks disabled because Digest::SHA not installed. Please consider installing the Digest::SHA module. CPAN: Compress::Zlib loaded ok (v2.008) Email-Reply-1.202/ Email-Reply-1.202/Changes CPAN: File::Temp loaded ok (v0.18) Warning: prerequisite Email::Abstract 2.01 not found. Warning: prerequisite Email::MIME::Creator 1.41 not found. Writing Makefile for Email::Reply ---- Unsatisfied dependencies detected during ---- ---- RJBS/Email-Reply-1.202.tar.gz ---- Email::Abstract [requires] Email::MIME::Creator [requires] Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] [Note: CPAN automatically detects that Email::Abstract and Email::MIME::Creator is required] Fetching with LWP: ftp://server/pub/CPAN/authors/id/R/RJ/RJBS/Email-Abstract-2.134.tar.gz make — OK make install — OK Fetching with LWP: ftp://server/pub/CPAN/authors/id/R/RJ/RJBS/Email-MIME-Creator-1.454.tar.gz make — OK make install — OK Warning: prerequisite Email::Simple::Creator 1.4 not found. Writing Makefile for Email::MIME::Creator Email::Simple::Creator [requires] Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] [Note: CPAN automatically detects that Simple::Creator is required] Fetching with LWP: ftp://carroll.cac.psu.edu/pub/CPAN/authors/id/R/RJ/RJBS/Simple-Creator.tar.gz make — OK make install — OK Fetching with LWP: CPAN.pm: Going to build R/RJ/RJBS/Email-Reply-1.202.tar.gz make — OK make install — OK
В примере выше Email::Reply зависит от нескольких других модулей. CPAN автоматически определил зависимости и установил Email::Reply и все другие необходимые модули.
У большинства MySQL серверов включено кэширование запросов. Один из наилучших способов улучшения производительности — просто предоставить кэширование самой базе данных. Когда какой-либо запрос повторяется много раз, его результат берется из кэша, что гораздо быстрее прямого обращения к базе данных.
Основная проблема в том, что многие просто используют запросы, которые не могут быть закэшированны:
// запрос не будет кэширован $r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()"); // а так будет! $today = DATE("Y-m-d"); $r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");
Причина в том, что в первом запросе используется функция CURDATE(). Это относиться ко всем функциям, подобным NOW(), RAND() и другим, результат которых недетерминирован. Если результат функции может измениться, то MySQL не кэширует такой запрос. В данном примере это можно предотвратить вычислением даты до выполнения запроса.
Используя EXPLAIN, вы можете посмотреть, как именно MySQL выполняет ваш запрос. Это может помочь вам избавиться от слабых мест производительности и других проблем в вашем запросе или в структуре таблиц.
Результат EXPLAIN покажет вам, какие используются индексы, как выбираются и сортируются таблицы и т.д.
Возьмите ваш SELECT запрос (он может быть сложным, с объединениями) и добавьте в начало ключевое слово EXPLAIN. Для этого вы можете использовать phpmyadmin. В результате вы получите очень интересную таблицу. Для примера, пусть я забыл добавить индекс в таблицу, которая участвует в объединении:
После добавления индекса для поля group_id:
Теперь вместо 7883 строк, выбираются только 9 и 16 строк из двух таблиц. Перемножение всех чисел в столбце rows даст число прямо пропорциональное производительности запроса.
Иногда, обращаясь к таблице, вы точно знаете, что вам нужна только одна конкретная строка. Например, нужно получить одну уникальную строку или просто проверить существование записей, удовлетворяющих запросу WHERE.
В этом случае, добавление LIMIT 1 в ваш запрос будет оптимальнее. Таким образом, база данных остановит выборку записей, после нахождения первой же, вместо того, чтобы выбрать всю таблицу или индекс.
// есть пользователи в Alabama? // можно так: $r = mysql_query("SELECT * FROM user WHERE state = 'Alabama'"); IF (mysql_num_rows($r) > 0) { // ... } // но так лучше: $r = mysql_query("SELECT * FROM user WHERE state = 'Alabama' LIMIT 1"); IF (mysql_num_rows($r) > 0) { // ... }
Индекс это не только основной или уникальный ключ. Это так же любые столбцы в таблице, которые вы используете для поиска и их можно проиндексировать.
Как вы можете заметить, это правило также применимо для части строк, например — «last_name LIKE ‘a%’». При поиске с начала строки, MySQL использует индекс этого столбца.
Вы так же должны понимать, что это не сработает для регулярных выражений. Например, когда вы ищите слово (т.е. «WHERE post_content LIKE ‘%apple%’»), то от обычного индекса не будет никакого толку. Лучше будет использовать полнотекстовый поиск или создать вашу собственную систему индексации.
Если ваше приложение содержит много объединений таблиц, вам необходимо проиндексировать в обеих таблицах поля, используемые для объединения. Это повлияет на то, как MySQL делает внутреннюю оптимизацию объединений.
Так же эти столбцы должны быть одного типа. Например, если вы объединяете столбец DECIMAL со столбцом INT из другой таблицы, MySQL не сможет использовать хотя бы один из индексов. Даже кодировки символов должны быть одного типа для строковых столбцов.
// выборки компаний в штате пользователя $r = mysql_query("SELECT company_name FROM users JOIN companies ON (users.state = companies.state) users.id = $user_id"); // обе колонки state должны быть проиндексированны // они обе должны иметь один тип данных и кодировку символов // а иначе MySQL сделает полную выборку из этих таблиц
(Имеется в виду выборка единственной строки. Примечание переводчика)
Это одна из тех вещей, который выглядят очень хорошо на первый взгляд, но многие начинающие программисты попались на эту удочку. Вы даже не представляете, какое слабое место в производительности возникнет, если будете использовать это в запросах.
Если вам действительно нужен случайный порядок строк в запросе, то есть лучшие способы сделать это. Конечно, это приведет к дополнительному коду, но позволит избавиться от слабого места в производительности, которое будет сужаться экспоненциально при увеличении данных. Проблема в том, что MySQL будет выполнять RAND() (а это нагрузка на процессор) для каждой строки при сортировке, выдавая только одну строку.
Таким образом вы выберите случайный номер, который меньше количества строк и используете его для смещения в LIMIT.
Чем больше данных считывается из таблицы, тем медленнее запрос. Это увеличивает время работы с хранилищем данных. Также, когда сервер базы данных установлен отдельно от web-сервера, будет большая задержка при передаче данных по сети.
Прописывать, какие именно столбцы из запроса вам нужны — хорошая привычка.
// не очень хорошо: $r = mysql_query(«SELECT * FROM USER WHERE user_id = 1»); $d = mysql_fetch_assoc($r); echo «Welcome {$d['username']}»; // лучше: $r = mysql_query(«SELECT username FROM USER WHERE user_id = 1»); $d = mysql_fetch_assoc($r); echo «Welcome {$d['username']}»; // разница более значительна при большем наборе данных.
В каждой таблице нужно поле id, которое будет PRIMARY KEY, AUTO_INCREMENT, а так же иметь тип INT. Так же неплохо, чтобы оно было UNSIGNED, т.к. вряд ли у идентификатора будут отрицательные значения.
Даже если в вашей таблице пользователей есть уникальное поле username, не делаете его основным ключом. Использование поля VARCHAR, как основного ключа, очень медлительно. Да и структура вашего кода, относящаяся к пользователям, будет гораздо лучше, если у каждого пользователя будет свой внутренний идентификатор.
Есть так же и внутренние операции MySQL, использующие первичный ключ. И это становиться очень важно для более сложных конфигураций базы данных (кластеры, распараллеливание и т.д.)
Исключение из этого правила составляют «таблицы ассоциаций», используемые для связи «многие-ко-многим» между 2 таблицами. Например, таблица «posts_tags», содержит 2 поля: post_id, tag_id, который используется для объединения между двумя таблицами «Posts» и «Tags». Эта таблица будет иметь первичный ключ составленный из 2 полей.
ENUM — очень быстрый и компактный тип поля. Значения в нем храниться так же, как TINYINT, но отображаются как в строковом поле. Это делает его незаменимым в некоторых случаях.
Если у вас есть поле, в котором будет вполне определенный набор значений, используйте ENUM вместо VARCHAR. Например, если есть поле «status», его значения могут быть «active», «inactive», «pending», «expired» и т.д.
Можно даже получить от MySQL «совет» о том, как перестроить таблицу. Если у вас есть поле VARCHAR, MySQL может предложить заменить его на ENUM. Для этого используется PROCEDURE ANALYSE(), описанная ниже.
PROCEDURE ANALYSE() анализирует структуру вашей таблицы и данные в ней, и выдает возможные советы по оптимизации. Это возможно только при наличии реальных данных в таблице, т.к. анализ делается в основном на их основе.
Например, если вы создали первичный ключ типа INT, а записей не очень много, MySQL может предложить заменить его на MEDIUMINT. Или, если используется VARCHAR в котором есть несколько уникальных значений, будет предложен ENUM.
В phpmyadmin в структуре таблице есть ссылка «Анализ структуры таблицы», результат которой может быть, например, следующим:
Если есть особые причины использовать NULL — используйте его. Но перед этим спросите себя — есть ли разница между пустой строкой и NULL (для INT — 0 или NULL). Если таких причин нет, используйте NOT NULL.
NULL занимает больше места и, к тому же, усложняет сравнения с таким полем. Избегайте его, если это возможно. Тем не менее, бывают веские причины использовать NULL, это не всегда плохо.
Из документации MySQL:
«Столбцы NULL занимают больше места в записи, из-за необходимости отмечать, что это NULL значение. Для таблиц MyISAM, каждое поле с NULL занимает 1 дополнительный бит, который округляется до ближайшего байта».
Если есть особые причины использовать NULL — используйте его. Но перед этим спросите себя — есть ли разница между пустой строкой и NULL (для INT — 0 или NULL). Если таких причин нет, используйте NOT NULL.
NULL занимает больше места и, к тому же, усложняет сравнения с таким полем. Избегайте его, если это возможно. Тем не менее, бывают веские причины использовать NULL, это не всегда плохо.
Из документации MySQL:
«Столбцы NULL занимают больше места в записи, из-за необходимости отмечать, что это NULL значение. Для таблиц MyISAM, каждое поле с NULL занимает 1 дополнительный бит, который округляется до ближайшего байта».
Есть множество преимуществ в использовании prepared statements, как для безопасности, так и для улучшения производительности. Prepared statements фильтруют значения данных, добавляемых в запрос, что защищает запросы от SQL инъекций. Конечно, вы можете фильтровать переменные вручную, но тут может сказаться человеческая забывчивость и невнимательность. Конечно, это не столь важно при использовании какого-либо фреймворка или ORM.
Поскольку статья посвящена оптимизации, отмечу также выгоды для нее. Они проявляются, когда запрос выполняется много раз в приложении. Вы можете использовать для prepared statement разные значения, но MySQL будет разбирать запрос только один раз.
Кроме того, последние версии MySQL компилируют prepared statements в бинарную форму, что позволяет повысить эффективность.
Раньше многие программисты избегали prepared statements по одной единственной причине — они не кэшировались MySQL, но с версии 5.1 это не так.
Посмотрите mysqli extension для использования prepared statements или воспользуйтесь абстракцией базы данных, например, PDO.
// создаем a prepared statement IF ($stmt = $mysqli->PREPARE("SELECT username FROM user WHERE state=?")) { // привязываем значения $stmt->bind_param("s", $state); // выполняем $stmt->EXECUTE(); // привязываем результат $stmt->bind_result($username); // получаем данные $stmt->fetch(); printf("%s is from %s\n", $username, $state); $stmt->close(); }
Обычно, делая запрос, скрипт останавливается и ждет результата его выполнения. Вы можете изменить это, используя небуферизованные запросы.
Хорошее описание есть в документации функции mysql_unbuffered_query():
«mysql_unbuffered_query() отправляет SQL-запрос в MySQL, не извлекая и не автоматически буферизуя результирующие ряды, как это делает mysql_query(). С одной стороны, это сохраняет значительное количество памяти для SQL-запросов, дающих большие результирующие наборы. С другой стороны, вы можете начать работу с результирующим набором срезу после получения первого ряда: вам не нужно ожидать выполнения полного SQL-запроса»
Однако есть определенные ограничения. Вам придется считывать все записи или вызывать mysql_free_result() прежде, чем вы сможете выполнить другой запрос. Так же вы не можете использовать mysql_num_rows() или mysql_data_seek() для результата функции.
Многие программисты хранят IP адреса в поле типа VARCHAR(15), не зная что можно хранить его в целочисленном виде. INT занимает 4 байта и имеет фиксированный размер поля.
Убедитесь, что используете UNSIGNED INT, т.к. IP можно записать как 32 битное беззнаковое число.
Используйте в запросе INET_ATON() для конвертирования IP адреса в число, и INET_NTOA() для обратного преобразования. Такие же, такие функции есть и в PHP — ip2long() и long2ip() (в php эти функции могут вернуть и отрицательные значения. замечание от хабраюзера The_Lion).
$r = "UPDATE users SET ip = INET_ATON('{$_SERVER['REMOTE_ADDR']}') WHERE user_id = $user_id";
Если каждая колонка в таблице имеет фиксированный размер, то такая таблица называется «статичной» или «фиксированного размера». Пример колонок не фиксированной длины: VARCHAR, TEXT, BLOB. Если включить в таблицу такое поле, она перестанет быть фиксированной и будет обрабатываться MySQL по-другому.
Использование таких таблицы увеличит эффективность, т.к. MySQL может просматривать записи в них быстрее. Когда надо выбрать нужную строку таблицы, MySQL может очень быстро вычислить ее позицию. Если размер записи не фиксирован, ее поиск происходит по индексу.
Так же эти таблицы проще кэшировать и восстанавливать после падения базы. Например, если перевести VARCHAR(20) в CHAR(20), запись будет занимать 20 байтов, вне зависимости от ее реального содержания.
Используя метод «вертикального разделения», вы можете вынести столбцы с переменной длиной строки в отдельную таблицу.
Вертикальное разделение — означает разделение таблицы по столбцам для увеличения производительности.
Пример 1. Если в таблице пользователей хранятся адреса, то не факт что они будут нужны вам очень часто. Вы можете разбить таблицу и хранить адреса в отдельной таблице. Таким образом, таблица пользователей сократиться в размере. Производительность возрастет.
Пример 2. У вас есть поле «last_login» в таблице. Оно обновляется при каждом входе пользователя на сайт. Но все изменения в таблице очищают ее кэш. Храня это поле в другой таблице, вы сведете изменения в таблице пользователей к минимуму.
Но если вы будете постоянно использовать объединение этих таблиц, это приведет к ухудшению производительности.
Если вам необходимо сделать большой запрос на удаление или вставку данных, надо быть осторожным, чтобы не нарушить работу приложения. Выполнение большого запроса может заблокировать таблицу и привести к неправильной работе всего приложения.
Apache может выполнять несколько параллельных процессов одновременно. Поэтому он работает более эффективно, если скрипты выполняются как можно быстрее.
Если вы блокируете таблицы на долгий срок (например, на 30 секунд или дольше), то при большой посещаемости сайта, может возникнуть большая очередь процессов и запросов, что может привести к медленной работе сайта или даже к падению сервера.
Если у вас есть такие запросы, используйте LIMIT, чтобы выполнять их небольшими сериями.
while (1) { mysql_query("DELETE FROM logs WHERE log_date <= '2009-10-01' LIMIT 10000"); IF (mysql_affected_rows() == 0) { // удалили break; } // небольшая пауза usleep(50000); }
Для базы данных работа с жестким диском, возможно, является самым слабым местом. Маленькие и компактные записи обычно лучше с точки зрения производительности, т.к. уменьшают работу с диском.
В документации к MySQL есть список требований к хранилищам данных для всех типов данных.
Если ваша таблица будет хранить мало строк, то не имеет смысла делать основной ключ типом INT, возможно лучше будет сделать его MEDIUMINT, SMALLINT или даже TINYINT. Если вам не нужно хранить время, используйте DATE вместо DATETIME.
Однако будьте осторожны, что бы не вышло как с Slashdot.
Два основных типа таблиц — MyISAM и InnoDB, у каждого есть свои плюсы и минусы.
MyISAM хорошо считывает из таблиц большое количество данных, но он плох для записи. Даже если вы изменяете всего одну строку, блокируется вся таблица, и ни один процесс не может ничего из нее прочитать. MyISAM очень быстро выполняет запросы типа SELECT COUNT(*).
У InnoDB более сложный механизм хранения данных, и он может быть медленнее, чем MyISAM, для маленьких приложений. Но он поддерживает блокировку строк, что более эффективно при масштабировании. Так же поддерживаются некоторые дополнительные функции, такие операции как транзакции.
Подробнее:MyISAM Storage EngineInnoDB Storage Engine
Используя ORM, можно получить определенную оптимизацию работы. Все, что можно сделать с помощью ORM, можно сделать и вручную. Но это требует дополнительной работы и более высокого уровня знаний.
ORM замечателен для «ленивой» загрузки данных. Это означает выборку данных по мере необходимости. Но необходимо быть осторожным, т.к это может привести к появлению множества маленьких запросов, что приведет к снижению производительности.
ORM также может объединять несколько запросов в пакеты, вместо отправки каждого отдельно.
Моя любимая ORM для PHP — Doctrine. Я уже писал статью об установке Doctrine в CodeIgniter.
Постоянные соединения предназначены для уменьшения расходов на установление связи с MySQL. Когда соединение создается, оно остается открытым после завершения работы скрипта. В следующий раз, этот скрипт воспользуется этим же соединением.mysql_pconnect() в PHPНо это звучит хорошо только в теории. Из моего личного опыта (и опыта других), использование этой возможности не оправдывается. У вас будут серьезные проблемы с ограничением по числу подключений, памятью и так далее.
Apache создает много параллельных потоков. Это основная причина, почему постоянные соединения не работаю так хорошо, как бы хотелось. Перед использованием mysql_pconnect() посоветуйтесь с вашим сисадмином.
Кстати, если кто еще не отключил автозапуск для дисков в своей windows, тот очень рискует быть зараженным нехорошим вирусом. Дело в том, что они используют файл autorun.inf копируя его в корень вашей usb-flash (как вариант) и затем, когда вы ее вставите в свой компьютер файл запустится автоматически и заразит вас. Как отключить сие дейсвтие мы расскажем вам в нескольких словах.
Вот ниже приводится текст
REGEDIT4 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCdrom] “AutoRun”=dword:00000000
Скорпируйте его в Блокнот. Затем сохраните обязательно с расширением .reg. Затем кликните два раза по этому файлу и согласитесь с внесением данных в реестр windows. И помните — не отключив autorun вы подвергаете себя, свой компьютер и своих близких большой опасности.