If its precise empirical data you're asking for, I would ask the same - 99%? ;)
The bottleneck is *always* at the database, which is constrained by the time it takes to shuttle bits-n-bytes back and forth from/to the database. Software optimization efforts at that level are wasted. The nice thing, though, is that database technology has advanced to the extent that a 5ms query under no load doesn't degrade too fast under heavy user load - unlike reflection.
I have a feeling that many of the core developers on the team have already put an extensive amount of reflection into the system. I have yet to see any code, but will be interested to do a performance evaluation on the existing kernel (if there is one :) . Furthermore, I'm very interested in using probing utilities to discover the extent to which particular segments of code are slowing the system down.
How does an application 'not care if it is subject to reflection'? Module isolation? Low coupling?
I'll reiterate that a straight forward OO implementation will be easier to maintain than would something that relies heavily on being generic. Usually, systems that are overly generic for the sake of saving development time spend far too much time developing a generic framework.
my2c
Best,
John C. Dale
Leo Simons wrote:
John C. Dale wrote:
I'm concerned about your mention of reflection. I really like reflection, and think it has many useful applications in the application development space, but should be kept out of any runtime application that has stringent scalability and performance requirements.
it should be kept out of *any* code that has stringent performance requirements.
Indeed! One should know when to use the right tool.
But in all applications I have ever developed using containers that use reflection
operations, (usually to do instantiation and facilitate late binding), those operations
have never turned out to be the bottleneck.
99% of time is spent doing I/O, waiting for locks, or doing actual processing.
If the development time gained by using some ingenious proxying or reflection
code you write once and use in the right place, is spent optimizing the bottleneck
code, your app becomes lighting fast.
The trick is to write most of your application so that it does not care whether
it is subject to reflection of any kind at any point. If it turns out that's your
bottleneck, you can always take it out and replace it with something efficient.
Here are some dramatic results:
ehm. Why are they dramatic? Reflection is known to be slow, yes, but I've yet
to see hard figures showing it being the bottleneck in any realistic system.
cheers!
- Leo
