To send the output somewhere else set debugfh:-
- $schema->storage->debugfh(IO::File->new('/tmp/trace.out', 'w');
+ $schema->storage->debugfh(IO::File->new('/tmp/trace.out', 'w'));
Alternatively you can do this with the environment variable, too:-
This issue is due to perl doing an exhaustive search of blessed objects
under certain circumstances. The problem shows up as performance
-degradation exponential to the number of L<DBIx::Class> row objects in
+degradation exponential to the number of L<DBIx::Class> result objects in
memory, so can be unnoticeable with certain data sets, but with huge
performance impacts on other datasets.
It has been observed, using L<DBD::ODBC>, that creating a L<DBIx::Class::Row>
object which includes a column of data type TEXT/BLOB/etc. will allocate
LongReadLen bytes. This allocation does not leak, but if LongReadLen
-is large in size, and many such row objects are created, e.g. as the
+is large in size, and many such result objects are created, e.g. as the
output of a ResultSet query, the memory footprint of the Perl interpreter
can grow very large.
The solution is to use the smallest practical value for LongReadLen.
-=cut
+=head1 FURTHER QUESTIONS?
+Check the list of L<additional DBIC resources|DBIx::Class/GETTING HELP/SUPPORT>.
+
+=head1 COPYRIGHT AND LICENSE
+
+This module is free software L<copyright|DBIx::Class/COPYRIGHT AND LICENSE>
+by the L<DBIx::Class (DBIC) authors|DBIx::Class/AUTHORS>. You can
+redistribute it and/or modify it under the same terms as the
+L<DBIx::Class library|DBIx::Class/COPYRIGHT AND LICENSE>.