i'll be the first to admin that i'm just spouting off here
a perl profiler would quickly reveal where the time is really being
spent.
> > I don't know if things have improved in the past few years, but about three
> > years ago I had to tune some bulk loading of a perl object cache from an
> >
On 12/19/05 10:49 PM, Mark D. Anderson wrote:
> I think many of use realize what a pig dog fetch*_hashref is relative to
> fetch*_arrayref.
>
> I don't know if things have improved in the past few years, but about three
> years ago I had to tune some bulk loading of a perl object cache from an
> R
I think many of use realize what a pig dog fetch*_hashref is relative
to fetch*_arrayref.
I don't know if things have improved in the past few years, but about
three years ago I had to tune some bulk loading of a perl object cache
from an RDBMS, and found that fetchrow_arrayref was about 5 times
f
On 12/19/05 7:51 PM, Sam Vilain wrote:
> On Mon, 2005-12-19 at 17:30 -0500, John Siracusa wrote:
I think you misunderstand what the tests are doing. They're meant to
highlight exactly the features that you're describing. Fetching objects
and
some of their associated objects in
On 12/19/05 7:35 PM, Mark D. Anderson wrote:
> Just following up on the "inheritance support" topic of a month ago, and
> wondering if support for the 3rd pattern for inheritance ("union mapping" --
> put all in one superset table) is coming soon? That is the one that we agreed
> would be a good fi
On Mon, 2005-12-19 at 17:30 -0500, John Siracusa wrote:
> >> I think you misunderstand what the tests are doing. They're meant to
> >> highlight exactly the features that you're describing. Fetching objects
> >> and
> >> some of their associated objects in other tables is a common task. Many of
Hi John -
Just following up on the "inheritance support" topic of a month
ago, and wondering if support for the 3rd pattern for inheritance
("union mapping" -- put all in one superset table) is coming
soon?
That is the one that we agreed would be a good first one
to tackle.
It sounds like this is
On 12/19/05 6:54 PM, Perrin Harkins wrote:
> On Mon, 2005-12-19 at 18:35 -0500, John Siracusa wrote:
>> If the number of iterations is fixed, you get a usable wallclock time in the
>> results.
>
> The danger here is that cmpthese does not use that, so the compare
> option is misleading. I got bit
On Mon, 2005-12-19 at 18:35 -0500, John Siracusa wrote:
> If the number of iterations is fixed, you get a usable wallclock time in the
> results.
The danger here is that cmpthese does not use that, so the compare
option is misleading. I got bitten by that once, assuming that
the :hireswallclock o
On 12/19/05 5:48 PM, Perrin Harkins wrote:
> On Mon, 2005-12-19 at 17:30 -0500, John Siracusa wrote:
>> Pass the "--time" and (optionally) the "--hi-res-time" flags to bench.pl to
>> see a wall clock comparison.
>
> Are you sure? I looked at Benchmark a while back trying to find a way
> to measur
On Mon, 2005-12-19 at 17:30 -0500, John Siracusa wrote:
> Pass the "--time" and (optionally) the "--hi-res-time" flags to bench.pl to
> see a wall clock comparison.
Are you sure? I looked at Benchmark a while back trying to find a way
to measure wall time with cmpthese() and couldn't find one. I
On 12/19/05 5:02 PM, Perrin Harkins wrote:
> On Mon, 2005-12-19 at 08:33 -0500, John Siracusa wrote:
>> Yes, the db itself will usually be the biggest performance drain. But the
>> point of this benchmark suite is to isolate the overhead caused by the ORM
>> itself.
>
> Aren't unnecessary extra q
On Mon, 2005-12-19 at 08:33 -0500, John Siracusa wrote:
> Yes, the db itself will usually be the biggest performance drain. But the
> point of this benchmark suite is to isolate the overhead caused by the ORM
> itself.
Aren't unnecessary extra queries the biggest source of overhead though?
That s
On Mon, 2005-12-19 at 08:33 -0500, John Siracusa wrote:
> > This is one of the major reasons why I've never bothered with optimising
> > performance for this situation - by coding in the correct manner, the
> > number of very small database hits is minimised. Then it doesn't really
> > matter how
This release includes an important bug fix for anyone using a custom
metadata subclass. It also requires a new Rose::DB for a more minor Pg
array bug fix. Here are the changes:
Rose::DB::Object:
0.59 (12.19.2005) - John Siracusa <[EMAIL PROTECTED]>
* Added in_array, any_in_array, and all_i
On 12/19/05 2:36 AM, Sam Vilain wrote:
> After some investigation, I'm afraid Tangram does not operate in the
> manner that this test script requires. It's not really a tool for
> mapping an existing database as the test expects.
Yeah, that's what I thought too, but some comments on IRC seemed to
16 matches
Mail list logo
