wrote in message news:748869f7-13bb-5bdd-6fec-399a33b79...@rhsoft.net...
Am 06.11.2017 um 12:09 schrieb Tony Marston:
wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net...
Am 05.11.2017 um 11:24 schrieb Tony Marston:
wrote in message
news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...
it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"
I have worked on software which provided lots of different options,
which means that you have to keep testing if an option is being used or
not. This is an overhead whether you like it or not.
maybe your implementation was bad
Everybody knows that carrying around code which is either rarely used or
not used at all is an overhead
everybody knows that claims without measure the impact are worthless
Some things are so obvious that they do not need scientific proof. For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car has
a heater which you only use when it's cold. It also has an air conditioner
for when it's hot. It has windscreen wipers, and a motor, for when it's
raining. When the temperature is mild and it's not raining it means that you
are not using any of this equipment, yet you are still carrying their
weight, and this weight is affecting your car's performance. I do not have
to supply any figures as proof as the car manufacturers keep telling us that
cars that weigh less perform better, which is why they try to reduce the
weight of as any components as possible.
It is the same with software. The more code you carry around that is not
being used then the worse it will perform. Esoteric code which uses clever
features to perform tasks which can already be performed with simple code
is, IMHO, an unnecessary complication which benefits only those lazy
programmers who are obsessed with reducing the number of keystrokes. Taking
out the rarely used complicated stuff and concentrating on making the
commonly used stuff as fast and efficient as possible is what drove the
efforts in the RISC architecture. I was around when that happened, so I know
what I'm talking about.
<snip>
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
