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

Ну ведь он, это и советует:
Не надо:


То есть prepare происходит для каждой записи, что неправильно - и по идее одно и то же, что вставка без prepare.
И как должно быть 



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

Разве это не правильно?

ramus, предложил верное решение.
позднее время, а также то,что чукча писатель, а не читатель(чукча -> я), и не позволило, вам увидеть эту мысль в моей фразе.
Каюсь

"хоть проц 2 ядра и рама 4 гига ."

У нас особо "одаренные" программисты таким образом "напрягали" гораздо более крутой сервер - 8 двухядерных итаниумов с 64 гигами оперативки.
Я не говорю, что это предложение панацея от всего, но то, что надо один раз отпарсить SQL, а потом многократно использовать с разными данными-это существенно облегчит жизнь серверу и админу.

"что prepare statement наоборот помогает, позволяет держать базе в кэше объект SQL statement, что избавляет от необходимости
каждый раз парсить запрос."
Как раз в Вашем варианте происходит парсинг для каждой строки лога, так как каждый раз строка разная, например
INSERT INTO log (ip, host, string) VALUES ('1.1.1.1', 'host_temp', 'string')
INSERT INTO log (ip, host, string) VALUES ('2.2.2.2', 'host_temp', 'string')

В предложенном мной варианте парсинг (в том числе определение плана выполнения) выполняется один раз, 
INSERT INTO log (ip, host, string) VALUES (:ip, :host, :string)
в области хранения SQL запросов ( SQL area) будет только ОДНА строчка (от нашей сессии). Число execute для нее будет равняться числу строк в логе.

В Вашем же случае число строк в sql area БД будет равно числу строк в логе и для каждой такой строки число execute будет =1.

PS
Лучше много раз по разу, чем ни разу много раз ;)

пишу следующее :

такой вариант работает только в том случае если лог не обноляется , но у меня он периодически обнуляется и получается что новая запись в базе не добавится пока кол-во строк в новом файле не будет больше чем  кол-во записей в базе , вообщем бред получается .
вообщем вопрос номер один "как определить что лог обновился а не просто еще не успел набрать того кол-ва строк что в базе"

У вас тут с логикой все совершенно жестко. Вам предложили пару вариантов, но вы их не хотите использовать, вместо этого изобретаете велосипед, и удивляетесь что ничего не работает. 
Чем Вам не нравится вариант с seek?

Добавлено @ 11:29

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

Это сообщение отредактировал(а) shamber - 26.1.2010, 11:30

box, у меня вот какой вопрос возник: если у Вас лог периодически обнуляется и этот процесс никак не завязан со скриптом, Вы, случайно, часть данных не теряете (которые добавилась после запуска скрипта, но до обнуления лога)?

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

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

что в моем предложении, мешает осуществить перечисленное вами?


Это сообщение отредактировал(а) shamber - 26.1.2010, 17:05

интересно, когда вы повторите функциональность обыкновенного tail?
который может следить хоть за дескриптором, хоть за именем...

приведите пожалуйста пример использования tail  в перле , а то я нашел только для командной строки .

А почему не хотите использовать tail коммандной строки из perl ? 

tail | perl самое простое.
либо perldoc -f open

Дак можно прямо в перл получать результат tail

нет.
я так понял, что вы не прочитали man tail ?