RTFM: www.sqlite.org/speed.html
там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
SQLite:
Average time:
0.00223562335968
странный результат. Запустил ваш тест на своем dev сервере (Ubuntu Server, ядро 2.6, Apache 2, PHP 5.2.6) и получил тот результат на который, как я понял, вы надеялись:
SQLite:
0.0226039886475
0.0238060951233
0.0236310958862
0.015144109726
0.0120120048523
Average time:
0.019439458847
MySQL:
0.0117030143738
0.011342048645
0.0117700099945
0.0126521587372
0.0117499828339
Average time:
0.0118434429169
Количество итераций увеличено до 500:
SQLite
…
Average time:
0.0125000824928
я учился печать в соло, шестой или седьмой версии. Прошел около 60 уроков, а потом бросил — просто не видел необходимости заниматься дальше. Приобретенного навыка хватает с головой. Впечатления от программы сугубо положительные.
не «Поддерживает css форматирование», а частично поддерживает CSS 2.1
Мне показалось, что подобные инструменты предназначены в первую очередь для быстрой/удобной генерации PDF, а не для конвертации.
Около 2-х лет назад мне нужно было разработать систему для конвертации веб страницы в pdf, причем важнейшим условием было сохранение идентичного внешнего вида — ни один из открытых php фреймворков подобного типа с этой задачей не справился.
Может быть лучше сделать экзепшн или вернуть код ошибки, в данном случае?
А как функции определить баг это или злоумышленник :-)
Допустим это баг, то она вернет «неожиданный» результат, который в следующей функции опять будет «откалабурен» и т.д. В конце концов это приведет к какому нибудь неправильному результату, например к пустой странице или warning совсем в другом месте. Вы как, программист поддерживающий систему начнете искать причину ошибки и вам придется раскрутить всю эту цепочку вызовов обратно, хотя если бы ваша функция изначально сигнализировала об ошибке, то найте место ее появления было бы гораздо проще
Т.е. данных подход («каламбур») отдаляет место появления бага от места его обнаружения, что вобщем то плохо :-)
имхо, такой под написания кода неоднозначен. Строгость в определении параметров функций — это сродни применению отступов, нормальных имен переменных, комментариев — т.е. то что называют хорошим стилем.
в большинстве современных моделей есть функция callid - запрос на атс о номере звонящего абонента, однако, например в Украине абсолютное большинство атс эту услугу не поддерживают.
двойственное число - это из другой оперы http://ru.wikipedia.org/wiki/%D0%94%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE
там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
SQLite:
Average time:
0.00223562335968
MySQL:
Average time:
0.00963790082932
SQLite:
0.0226039886475
0.0238060951233
0.0236310958862
0.015144109726
0.0120120048523
Average time:
0.019439458847
MySQL:
0.0117030143738
0.011342048645
0.0117700099945
0.0126521587372
0.0117499828339
Average time:
0.0118434429169
Количество итераций увеличено до 500:
SQLite
…
Average time:
0.0125000824928
MySql
…
0.0096476111412
Мне показалось, что подобные инструменты предназначены в первую очередь для быстрой/удобной генерации PDF, а не для конвертации.
Около 2-х лет назад мне нужно было разработать систему для конвертации веб страницы в pdf, причем важнейшим условием было сохранение идентичного внешнего вида — ни один из открытых php фреймворков подобного типа с этой задачей не справился.
А как функции определить баг это или злоумышленник :-)
Допустим это баг, то она вернет «неожиданный» результат, который в следующей функции опять будет «откалабурен» и т.д. В конце концов это приведет к какому нибудь неправильному результату, например к пустой странице или warning совсем в другом месте. Вы как, программист поддерживающий систему начнете искать причину ошибки и вам придется раскрутить всю эту цепочку вызовов обратно, хотя если бы ваша функция изначально сигнализировала об ошибке, то найте место ее появления было бы гораздо проще
Т.е. данных подход («каламбур») отдаляет место появления бага от места его обнаружения, что вобщем то плохо :-)
Такой прием — хороший пример багописания.