Re^3: Optimizing a large project.

You're saying that use warnings FATAL => 'all'; with eval wrappers is a bad plan? You're saying that your test suite isn't adequate to exercise what has been changed?

Frankly, saying "We absolutely have no margin for error" is screaming "We need to have better plans for runtime error-handling." Perl can only do so much at compile-time. Are you saying that you don't have a simple hash-access with a variable? Nothing along the lines of if ( $foo{$bar} ) { ... }? Every single access is hard-coded? If that sort of safety is of such a major concern, you are using the wrong language.

That said, milliseconds is normal. Most webapps have a response time of more than 1000 requests/second. Have you considered using some sort of tied hash that would restrict which keys can be used? There's several implementations on CPAN for that sort of thing. The cost of tying is about 15% total. Almost nothing for your response time requirements.

And, error-handling isn't optional. Fast is worse than worthless if it's incorrect.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^3: Optimizing a large project. Select or Download Code

Replies are listed 'Best First'.
Re^4: Optimizing a large project. by salva (Canon) on Jun 13, 2008 at 08:01 UTC
The cost of tying is about 15% total Where did you get this measure? While developing Tie::Array::Packed I did some measurements and found my tied arrays (I know, we are talking about hashes here, but I don't thing there is going to be any significant difference) to be around 15 times slower (that is, 1400% performance penalty) than regular ones, and we are talking about a highly optimized XS implementation of the tie interface with almost no logic behind. The equivalent pure Perl implementation Tie::Array::PackedC was 60 times slower. What this penalty represents inside the whole application is completely dependent on how often the tied objects are accessed. I don't thing you can claim it is 15% or anything else, it just depends!	[reply]
Re^5: Optimizing a large project. by dragonchild (Archbishop) on Jun 13, 2008 at 14:01 UTC
That's funny. I was trying to find the reference and I can't. It's a number that's been in my head for years. Could be wrong. Huh. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: Optimizing a large project. by dextius (Monk) on Jun 13, 2008 at 13:54 UTC
I'm sorry, this isn't a web application (where you have multiple servers, cores and apache instances). This is a single threaded application, some of the most critical code in the system has been profiled to run in microseconds. Are we using the wrong language? It's funny you say that, it's been a topic around here recently. I talk to the C++ guys we work with and they tell me we'd be insane to try and move our business logic to C++, it is just too hard to manage long term. The only other options are Java, or C# (I hope to avoid going down that path). Perl meets and exceeds our expectations of what is possible of a scripting language, this post was an attempt to try and take "it" to the next level, based on what we thought MIGHT be the issues. I humbly disagree with your assessment of our approach on compile time safety for attribute lookup, if you'd like to further discuss this, feel free to drop me a line (ryan-dot-dietrich-at-gmail-dot-com)	[reply]


Perl Monk, Perl Meditation
	PerlMonks