Re: What's the best module to stop mixing SQL with Perl?

I would like to avoid the performance hits that Class::DBI and DBIx::Class impose.

Is this measurable? I assume that a decently-written application will spend a lot more time contacting the database and waiting to prepare, calculate, and retrieve results than it will executing Perl ops. IO is slow; network IO even slower.

Comment on Re: What's the best module to stop mixing SQL with Perl?

Replies are listed 'Best First'.
Re^2: What's the best module to stop mixing SQL with Perl? by perrin (Chancellor) on Sep 08, 2006 at 22:16 UTC
That is true, but in some cases the way the tools use SQL itself is inefficient compared to what you would write by hand. Rose::DB::Object and DBIx::Class avoid this for the most part though. See this benchmark for some comparisons.	[reply]
Re^2: What's the best module to stop mixing SQL with Perl? by Withigo (Friar) on Sep 08, 2006 at 22:11 UTC
I am basing my assumptions on this; which I originally found linked in a Rose::DB thread on here.	[reply]
Re^2: What's the best module to stop mixing SQL with Perl? by bart (Canon) on Sep 09, 2006 at 12:15 UTC
It depends on the application. The reason is not because of the construction of the SQL, but because of using one query per command. That can be damn slow: if you try to add a lot of data (ten thousands of records) into the database, using such a module can take 15 minutes where a plain native import takes 10 seconds. That is 2 orders of magnitude slower. Plain DBI is somewhere between these two extremes. For single record access, it'll hardly make a difference, it's just a matter of milliseconds.	[reply]