Re: [Modeling-users] Fetching raw rows

[Mario R. <ma...@ru...>]

On Jeudi, juil 17, 2003, at 19:23 Europe/Valletta, Sebastien Bigaret=20
wrote:
>
> Mario Ruggier <ma...@ru...> wrote:
>> On jeudi, juil 17, 2003, at 16:43 Europe/Amsterdam, Sebastien Bigaret=20=

>> wrote:
>
> Hey, you probably meant: "at 16:43 Europe/Paris" ;)

Ha! It's annoying isn't it? It insists on adding the time and place of=20=

the message
being replied to, but the place is the receiving end (or, worse, where=20=

it thinks the
receiving end is -- when setting is Geneva, it uses Zurich! Hey, i'd=20
rather be in
Amsterdam than in Zurich ;).  Plus, there is some language interference=20=

between
my settings and the system settings... Anyway, it is Apple Mail 1.2.5=20
client, and
actually if anyone knows how to configure the leading text that is auto=20=

added
to replies, i'd like to know! (not found how to do it yet)

>>>   Full functionality has been integrated in cvs yesterday evening,=20=

>>> and I've
>>>   completed the documentation today. All this will be in the next=20
>>> release.
>>
>> Attempting, and failing, to keep up with you... ;)
>
> Do you mean that you tested it and it failed? I've committed today
> afternoon slight changes, because of an unhandled situation when using
> nested ECs. However it shouldn't have failed in a "standard" =
situation.
> Could you be more explicit?

No, did not try it. Failing -- in terms of keeping up with your dev=20
rhythm ;)

...
> I've a test db w/ 5000 simple objects, I'll try some test and
> report. This could be added in the unittests, right.

Thanks for the numbers! It helps with the overall picture of what goes=20=

on...
However, just a question about the raw fetch:

> [raw row] 1st fetch (ec empty):                0.618131995201
> [raw row] 2nd fetch (objects already loaded):  0.61448597908
> [raw row] 3rd fetch (objects already loaded):  2.24008309841
...
>   2. You probably already noticed that fetching raw rows is
>      significantly slower when the objects are loaded. The reason is
>      that objects already loaded are checked for modification, because
>      as I explained it in my previous post we have to return the
>      modifications, not the fetched data, if an object has been
>      modified.

OK, i see why the 2nd fetch in this case could be significantly longer.
But, why the 3rd? Barring any modifications to the loaded objects,
there should not be any differences between 2nd and subsequent
raw fetches?


>> And, the classic fetch may be further broken up into two, one built=20=

>> with
>> Qualifiers and the other with RawQualifiers (as per recent thread),=20=

>> to keep
>> an eye on this known possible bottleneck on the system.
>
>   Sorry, I think I won't do this: we've just clarified the API, I do=20=

> not
> feel like splitting the fetch in two. However, what I *will* do is:
>
>   1. document the alternate (and less cpu-consuming) way of building
>      qualifiers,
>
>   2. add a section in the user's guide dealing with performance =
tuning,
>      and explaining this particular point among others.
>
> I think this should be enough, isn't it?

I only meant have two versions of a sample qualifier for a specific=20
query,
and use it in an internal test/profiling script... nothing at all for=20
the public api!

> -- S=E9bastien.

mario