Re: Sanitising input [message #172131 is a reply to message #172122] |
Mon, 31 January 2011 12:51 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/31/2011 12:38 AM, Ross McKay wrote:
> On Mon, 31 Jan 2011 00:10:00 -0500, Jerry Stuckle wrote:
>
>> About 4 months ago. PDO is still slower. It has to use the same mysql_
>> functions that PHP uses - it just adds an additional layer before
>> calling them. I got a significant performance increase simply by
>> dropping PDO in favor of native calls.
>
> Sounds like you must have had poor PDO code, and rather than fix it, you
> replaced it with good mysql_* code. Others do not find significant
> performance increases. But go ahead, blame PDO instead of your ability
> to use PDO correctly :)
>
No, the PDO code was good. And it was not my code. But you obviously
have not had to deal with high traffic sites and/or do not know how to
properly design/optimize a database.
>>> But minimal overhead, compared with the actual database statement
>>> execution.
>>
>> An overly broad statement which is not at all absolutely true. The
>> overhead of the bound parameters may easily exceed that of an efficient
>> statement execution. And whether the overhead is minimal or not - it is
>> still added overhead.
>
> Sure, broad... but typical. There are always cases where optimisation
> finds a better way. I have yet to be seriously hamstrung by using PDO
> over mysql_* or pg_*.
>
See above.
>>> First crawl, then walk, then run. I'd rather the OP got to running with
>>> two intact feet. Then they can determine the best way. ITMT, their
>>> question has been well answered by several posters now, and they get to
>>> pick their path.
>>
>> Yes, and I've found in over 20 years of corporate programmer training
>
> Appeal to accomplishment -- noted. Shall we measure, or will you accept
> that I have one too?
>
Your overly broad statements show otherwise.
>> that it's best to teach the lower level stuff first, along with the
>> gotchas and restrictions. That way the programmer better *understands*
>> the process - and can make more informed decisions.
>>
>> I've seen people who always try to take the quick and easy way out. It
>> works for a while - but eventually it comes back to bit them every time.
>> That's why I was able to make several thousand dollars converting the
>> site from PDO to native calls - the guy who first wrote it thought PDO
>> was the slickest thing since snot on a doorknob and couldn't be beat.
>> Well, he was wrong, and unfortunately it cost the customer.
>
> Again, sounds like some bad PDO code that could have been written better
> but you (over?) charged the customer to convert vast tracts of it from
> PDO to mysql_* because... you don't know enough about PDO?
>
People pay my rate because they know I produce - as in this case. The
original programmer did an OK job with the code, but performance fell
when traffic grew.
And yes, I know a lot about PDO - I've used it on many projects over the
years. But I also know where it fails - and performance is not its
strong point.
After all - PDO eventually has to call the mysql_xxx functions.
However, there is the additional layer in PDO which takes processing
time on a busy system.
> As for snot on door knobs, I've yet to find a database interface that
> I'm entirely satisfied with, and PDO leaves a lot to be desired (e.g.
> only has parameter bindings for string, int, boolean, null and blob).
> But I certainly wouldn't teach a new hire to use different and sometimes
> conflicting interfaces for different databases when there is a somewhat
> unified one at hand, especially when its performance is near native.
>
Every database has its own extensions. I don't try to teach a
programmer 10 different databases at once. Find the database they're
going to be using. Teach ANSI standard SQL plus the interface and
extensions (and, in MySQL's case, restrictions) for the database they
will be using.
>>> Optimise last!
>>
>> UNDERSTAND FIRST!
>
> Perhaps you should try that one too :)
I do. And that includes both the advantages AND DISADVANTAGES of using
something.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|