|
|
Posted by Michael Fesser on 11/25/07 16:37
..oO(Knut Krueger)
>> CPU cycles have nothing to do with it. This is all about good
>> programming techniques.
>>
>sure are CPU cycles and therefore SQL queries a question especially at
>an internetserver.
An if-branch or a function call really mean nothing to the CPU. But as
said elsewhere in this thread, it would be better to use two separate
functions, one for SELECT, another for INSERT/UPDATE/DELETE. This avoids
the problem right from the beginning. Couldn't be more efficient.
>> It is much better to not make the call you know is going to cause an
>> error in the first place. The way you're doing it is just sloppy
>> programming. Such techniques are problems just waiting to happen.
>
>If the record is more than 50% available, then there are less sql
>queries with the suppress error method otherwise with the other method
>is better.
Huh? The DB queries are the same. The difference is how the results (or
better the non-results) are handled.
>I started programming with assembler and 8068 processors and in this
>time everybody must take care about CPU and memory usage.
PHP is not assembler, it's a much more abstract language. Optimization
in PHP starts on the algorithms, not on single CPU instructions or
language constructs. Google "premature optimization" if you want.
>In both cases the error handling was important but it was in different ways.
>and using the @ including an error handling should not a bad programming
>style if the usage of the server is more less.
>
>Therefore I my mind there is still the question which way is with less
>cpu usage. That's not the question for one user, but for 1000 users
>simultaneously
If you run into performance problems, use a profiler to find the real
bottlenecks. It will definitely not be the error handling.
Micha
Navigation:
[Reply to this message]
|