AKA Panama Jack wrote:BDKR wrote:I do not agree with your contetion that parsing is of little concern. Did you look at the benchmarks on Panama Jack's site? Notice the increase in speed for Adodb when an accelerator was used? The percentage of increase is greater then 3 fold! Parsing makes a huge difference.
Parsing can be a huge and costly operation. There is no way around that fact. Just use an accellerator and be done with it.
This is one of the main problems I have with most programmers today.

We have the memory and accellerators so who cares about how fast the code is right now. Throw it together and if we need speed make sure the server is using some kind of PHP accellerator. If a programmer is trained to create small and efficient code from the start then they can create the code just as fast if not faster than someone who just goes for what works at the time. Most programmers that are churned out from most courses are not trained in making the code tight and efficient but they are definately trained on making it look PRETTY. That gets my panties in a bunch.

You can make the code easy to follow and well laid out while making it tight and fast.
I suspect you arrived at a conclusion about me based on just the comments above. If anybody on this board has been called or considered a code-smith in the past, I have been. Of course they use it in that derogatory tone while the "pre-mature optimization" song is rattling along in their heads. Of course, I've also got the Rodney Dangerfield treatment as I've chosen to not go OOP in the past for performance reasons. Of course they then automatically say that my design is faulty or quesitonable without even knowing the particulars of the requirements.
Not knowing your experiences in development, I'll guess based on what you've done and said that you had to deal with concerns that relate to performance. Well, that's the case for me too. In the best example, I spent 3 years designing, building, and maintaining a fault tolerant cluster that saw dead serious levels of load and brutal spikes that normally lasted about 15 minutes at each occurrence. It was the nature of the business we were in. In those spikes, we would often see over a million queries in a 5 minute time span (and to think that the pundits claimed MySQL couldn't do it! LOL).
We also
HAD to be mindfull of the performance of our code as getting hardware in the Third World could be problematic. And we weren't running crap either. The database servers were Supermicro Pedestals with Serverworks dual proc boards. We also ran Ultra 160 controllers which were the cream of the crop at the time with Seagate SCSI drives. That stuff was
hard to find so we allways ordered from the states, which meant we risked the possibility of having items stolen in the mail/shipping process (no joke). Being that we were also a cash starved startup at times didn't help matters either.
In other words, we couldn't just "throw hardware at it" as I've heared a lot of Jack Boot wearing application developers state. That may be just fine (and needed when you get into that object-relational stuff) but it serves to prove that their experience is limited to application development with no experience in mission critical stuff.
So, to put my comment in context, I feel that one has no room to complain about the up front parsing hit if their requirements are for a library means that it's big. If that's the case, you live with it and one of the ways to do that is to use an accellerator.
Now, if you've thrown in the kitchen sink or used a lib with the kitchen sink in it without giving much thought to your needs, then don't complain to me about it. But you too
had better use an accellerator in this case.
AKA Panama Jack wrote:
Well, it's great to have all of those extra tools even if you don't currently need them.
Yes and no. Let's continue the analogy a little and extend it to the space required to store them. At my house, I have a one car garage. What that means is that while my car was being turbocharged and parked in there, the amount of space was severly limited. That meant being thoughtful of where I place/stored all of my tools so that I still had room to work. Often times I had to move something out of the way while working on a certain part of the car. There often were times when I needed to stop work and just clean up before things got too out of hand. Like putting away tools that weren't being used (sound like garbage collection?) as an example.
The analogy of course is to memory allocation. There is an overhead to memory management that the engine suffers to some degree depending upon various things, including the instantiation of large objects. If you have limited resources (space) and are at least moderately loaded, you may want to consider the size of the tool set no?
In this case, I want a memory upgrade in the form of a shed in the back yard where I can put non-car related tools.
AKA Panama Jack wrote:
And having those extra tools won't slow you down unless you are silly and try to use them all at the same time.
This is the the interesting thing in comparison to some other languages. Objective C is an example. There is not a slow down in method look up as the number of methods increase inside an object.
Oh well.... back to work.