Hmm. It's never that easy.

As it turns out, DProf segfaults while Devel::Profiler screws up the file when confronted with my scary class definition logic. What I'm doing is VERY insecure, so only do this if you TRUST your users.

I've designed it so that one general class is a shell around the class I load. I've done this for several reasons

1. If there is a syntax error in one of the classes, I don't want bring down the entire process.
2. I want to give my customers the chance to create their own code that ties in, without altering the core code
3. I got a performance improvement when using this method over regular inheritance

Anyhow, I have a class. The objects have an associated file, and that file contains part of the code - using a standard API. So, I create a header and a footer, and insert the code from the file inbetween. Then, I run a string eval around that, and then I have a new child class. I create an object of the child class, and keep it as a variable in the parent class. Inside the parent class, I call that object where appropriate.

As it turns out, the profilers do not approve of this.

Any brilliant ideas, fellow monks? Need I rewrite, or do you see a way for me to work around my problem?