|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Ruslan Bondarev 2:463/94.12 30 Dec 2001 00:04:13
To : Pavel V. Reich
Subject : Re: CGI.pm: POST отделить от GET
--------------------------------------------------------------------------------
Пятница Декабрь 28 2001 21:07, Pavel V. Reich -> Ruslan Bondarev:
PR> Вот сколько читаю эху - одного не пойму: почему идут постоянные споры
PR> CGI.pm vs процедурки руками? Hу если экономить время исполнения -
PR> тогда лучше писать на С/С++ (а то и на ассемблере ;). Зачем люди
PR> мучаются и пишут самостоятельно второй велосипед CGI.pm?
не только CGI.pm; уже есть попытки переписать более серьезные скрипты, типа
Net::DNS. это оправдано, если хостинг не предоставляет нужных модулей. если же
предоставляет, то причина кроется в:
желании оптимизировать свою программу; боязнь прочитать документацию к
готовому решению; недоверие к чужим программам.
два последних случая относятся к компетенции психоаналитиков, а по поводу
первого хорошо рассказывает Joseph Newcomer в своей статье "Optimization: Your
worst enemy". позволю себе процитировать.
=== Start of Windows Clipboard ===
A reasonably skilled programmer will not write a grossly inefficient program. At
least not deliberately. Optimization is what you do when the performance is
insufficient. Sometimes the optimizations are easy, sometimes they are hard.
Sometimes they fly in the face of your original design, and sometimes they
require that you grossly violate your beautiful abstractions in your class
system. But always, and I repeat, *always*, my experience has been that no
programmer has *ever* been able to predict or analyze where performance
bottlenecks are *without* data. No matter where you think the time is going, you
will be surprised to discover that it is going somewhere else.
You optimize because you have a problem in performance. Sometimes it is
computational optimization: your bitmap manipulation is just too slow. Sometimes
it is data access optimization: it just takes too long to get the data into the
machine. And sometimes it is algorithmic optimization: you're doing it wrong. If
you don't understand the difference between an n^2 sort and an n log n sort,
you're probably already in trouble, but that knowledge alone is not useful.
Some years ago, I was working on a complex program which had to perform a
semantic cross-check between the "statements" of the program and the
"declarations" (it was actually a 4GL constraint equation system, but the
details don't matter). I discovered that the operation was of n^3 complexity
(well, actually m * n^2, but m and n would be of comparable size most of the
time). There are three paths that you can follow here:
- The naive path. You don't even realize you've got an n^3 problem. You're
probably in trouble, because if it is the bottleneck, you didn't know it was
there.
- The formal academic path. You realize you've got an n^3 problem, and know it
is intrinsically evil, and rewrite your algorithms.
- The engineering path. You realize you've got an n^3 problem, but you
instrument the system to discover its actual impact on the system.
The only valid path to optimization is the engineering path. I measured the
performance, and on the largest "real" example we had, I discovered that n was
almost always 1, sometimes 2, rarely 3, and had exactly one instance of 4. This
was too small to matter. Sure, the algorithm was n^3, but with n that small,
there was no need to rewrite the code. Rewriting the code would have been
incredibly complex, delayed the whole project for a couple weeks, and used up a
couple pointers in each node of the tree in an already-tight minicomputer
address space.
=== End of Windows Clipboard ===
... bye.
--- Медленно любила, пережевывая...
* Origin: (2:463/94.12)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
