At 05:38 AM 4/10/99 -0500, you wrote:
>> > You could use the standard C API that comes with MySQL. It
>> > will be faster than an interpreted language like Perl or PHP
>> > or Python.
>>
>> I am very curious. I have not programmed in C. 99% of my
>> experience is with perl. I am of the impression that the same
>> functions can be programmed in perl in much less time than in C;
>> a programer using perl could get the same work done in say 50%
>> of the time needed to do it in C.
>
>
>that's a dangerous comparison.. there are many factors in
>development speed, and choice of language is only one of them.
>
>it's well documented that there are order-of-magnitude
>differences in productivity between programmers with identical
>resumes, working in the same language, and on the same project.
>both IBM and NASA have done such studies, and the results were
>the same both times. some people get ten times as much done as
>others, even when they're in neighboring cubes.
>
>when you factor in the difference between someone who knows the
>problem domain and somone who doesn't, you add another one or
>two orders of magnitude. it's entirely possible for a
>programmer who knows the moves to whip out a piece of code in
>1/1000th the time of one who's still trying to learn the moves.
>
>i'm not kidding, either.. the 1000:1 difference is 1 minute vs
>16 hours. a one-liner for Ralph, and two work-days of
>tinkering for Fred. if you count the absolute time, as in
>"when can we ship?" (which is *precisely* how the marketing &
>finance departments measure things), those sixteen hours will
>all take place in one stress-filled day of overtime.
>
>the upshot is that when one programmer can be a thousand times
>as fast as the next, in the same language, comparisons between
>different programmers in different languages get just a bit on
>the loose side.
>
>in very broad terms, interpreted languages tend to be faster &
>easier for small (less than 5000 executable statements)
>programs, and execution environments which can absorb a lot of
>slop. compiled languages, by contrast, tend to be better for
>large programs, and execution environments where overhead needs
>to be minimized. if you're going to base your choice of
>language on anything, ask yourself how much an extra tenth of a
>second really matters.
This I agree with.
>CGIs, on average, tend to fall in the category where interpreted
>languages are strongest. even it your script is being hit
>100,000 times per day, that only averages to 1 instance per
>second. most of today's server hardware can handle that
>without noticing. in that context, the benefits of fast
>one-liners and easy updates outweigh the additional overhead.
Not in my experience. I used to run a chat room that was a perl
script. The overhead of the perl program was HORRIBLE. I
re-wrote it in C/C++ and got more than a 1000x improvement.
Granted that was a more specialized case. But to the best of my
knowledge, everything I have seen written in PERL is good for a
low use kinda project (I still use it for low-impact programs),
but if you are talking anything that has to deal with tons of IO,
file manipulations (locking, re-writing, etc), large numbers of
instances, then C/C++ has shown me that it is MUCH more efficient
in terms of overhead.
Granted, this might be more of a 'large' program than a simple form.
Speed of C vs PERL does depend on the end result of the program
(how many tables is it working with, how complicated are the
joins, how much is data manipulation is to be done before
displaying output, etc).
>the value of single-line power decreases as the size and
>complexity of a program increase, though. translating the
>Apache source tree over to perl wouldn't make that code any
>easier to develop or maintain. for projects of that size,
>well-defined subsystems and interfaces are more important than
>how much you can do on a single line. meanwhile, the overhead
>of the interpreter increases geometrically with the program's
>size, so a perl version of Apache would be less desirable than
>the current version in C.
Although there are things like the miniserve.pl written in perl
(the server that Webmin uses) that has decent speed (but that
isn't designed for 100K pages a day).
>'development speed' and 'efficiency' are topics programmers tend to
>toss around like frisbees, without ever linking them to specific
>issues of the job at hand. among the possible things that can
>be defined as 'good' in code are:
>
> - freedom from bugs
> - richness of feature set
> - speed of development
> - portability
> - readability
> - ease of maintenance
> - ease of upgrade
> - execution speed
> - efficient use of system resources
>
>
>most of which are mutually exclusive. code that screams is
>usually unreadable, almost always a resource hog, and only
>portable through the purest of luck. the same is true for
>programs written in a code blitz, except those generally aren't
>very fast, either. portable code is slow as hell to write, and
>usually plods along in execution, but it tends to be less buggy
>and easier to maintain & upgrade. the list goes on ad nauseam.
I agree with most of this, except for portable code being slow
to write. I tend to write most of my software using standard
functions (no M$ type proprietary extensions, etc). I tend to
always use GNU/GCC as my compiler base. I have seldomly had to
change anything (depends on versions of the same compiler). My
software has compiled bug free (or at least no new ones *g*) on
BSDI Unix, RH Linux, FreeBSD 2.2.x and 3.x, Sun Solaris, and on SGI IRIX.
>part of the implementation programmer's stock in trade is
>choosing the tradeoffs which fit the circumstances of the
>current project. i've personally never seen a webserver that
>consistently runs at more than 5% of its capacity, so i doubt
>the added speed of the C library for MySQL would be sufficient
>to justify it over perl in most cases. OTOH, if you already
>like coding in C and are familiar with the library, i see no
>reason to drop it in favor of perl.
The site that Camille and and I work for (as a consultant) is
getting over 100K page views (not hits- 100K pages is like 810K
hits) each and every day. The server (a P300 w/512MB of RAM) is
constantly at 95% CPU utilization. So I know first hand the
problems of PERL vs. C on a heavily loaded CPU/SERVER.
At our peak times, it is normal for us to have 200 simultaneous
connections and at non-peak times, we are usually at 125 connections.
>in general terms, the best program is the one that's in
>production and not giving you problems. whatever language &
>utilities get you there are good enough.
This is true. And as long as the performance you get is
adequte, then that is enough.
>in answer to your original question, i doubt you'll find a
>non-geek oriented piece of middleware that offers you good
>flexibility. i'll second Steven's suggestion for PHP.. it's a
>good package which emphasizes template-driven database
>interaction.. but if you're doing anything complex, you'll
>probably want to find a geek.
Matt Soffen
==============================================
Boss - "My boss says we need some eunuch programmers."
Dilbert - "I think he means UNIX and I already know UNIX."
Boss - "Well, if the company nurse comes by, tell her I said
never mind."
- Dilbert -
==============================================
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
