As to the startup overhead of DBIx::Class, that is a real concern at this point, especially if your code runs in short-lived processes. Your progammer could have been talking about either or both of the following startup performance hits:
First, he could be talking about dynamic schema loading via DBIx::Class::Schema::Loader at app startup. This will always be slow, there's not too much we can do about that. On the other hand, dynamically loading the schema from the database via Loader is really only recommend for development work and/or trivial schemas. For a production application, nobody would recommend using Loader at runtime.
You can either manually define the corresponding DBIx::Class schema, or you can use DBIx::Class::Schema::Loader in "one-shot" mode to generate the schema classes on disk each time you make schema modifications in development, and then use those static classes in production.
The other startup-time performance concern is DBIx::Class's use of Class::C3 for sane multiple inheritance. Class::C3's initialization involves considerable overhead at startup time, and some minor performance overhead at runtime. This startup hit is considerably less than the Loader one above, but you'd still notice it in profiling, especially for short-lived processes.
I'm in the process of working up a patch against bleadperl to put C3 method resolution (as an optional per-package pragma) into the perl core, which is about the only sane way to improve the situation given the deep interactions with perl's method caching. I can't really offer any guarantees as to when this will be completed and/or if p5p will accept it into the canonical perl core (hopefully in time for 5.10.x?), but I'm actively working towards these goals.
-- Brandon
In reply to Re: Creating a model of a bad database
by ph713
in thread Creating a model of a bad database
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |