 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Efim Mett
Guest
|
 Posted: Fri Feb 02, 2007 12:06 am Post subject: ensureObjects: why so? |
 |
|
Hi,
just wondering about duration of EnsureObjects on different lists.
2 experiments:
1. ClassA: has 5,5 Mio persistent instances.
2. ClassB: has 0,5 Mio persistent instances
MyClassAList: TClassAList;
MyClassBList: TClassBList;
........
MyClassAList := BoldSystem.evaluateExpressionAsNewElement ('.....') as
TClassAList;
MyClassBList := BoldSystem.evaluateExpressionAsNewElement ('.....') as
TClassBList;
ShowMessage (IntToStr (MyClassAList.count)); // Output: 1000
ShowMessage (IntToStr (MyClassBList.count)); // Output: 1000
MyClassAList.ensureObjects; // Duration: 20 sec. !!!
MyClassBList.ensureObjects; // Duration: 2 sec.
Why is the time difference so large??
I obserbved the behaviour in SQL Server Profiler. For each EnsureObjects
were 4 SELECTs executed: 250 IDs per portion. Execution time was apparently
not the problem, but pauses between SELECTs were drastically longer for
ClassA. I can't explain it myself.
/Efim |
|
| Back to top |
|
 |
Jan Nordén (CodeGear)
Guest
|
| Posted: Fri Feb 02, 2007 9:12 am Post subject: Re: ensureObjects: why so? |
|
|
Efim Mett wrote:
| Quote: | Hi,
just wondering about duration of EnsureObjects on different lists.
2 experiments:
1. ClassA: has 5,5 Mio persistent instances.
2. ClassB: has 0,5 Mio persistent instances
MyClassAList: TClassAList;
MyClassBList: TClassBList;
.......
MyClassAList := BoldSystem.evaluateExpressionAsNewElement ('.....') as
TClassAList;
MyClassBList := BoldSystem.evaluateExpressionAsNewElement ('.....') as
TClassBList;
ShowMessage (IntToStr (MyClassAList.count)); // Output: 1000
ShowMessage (IntToStr (MyClassBList.count)); // Output: 1000
MyClassAList.ensureObjects; // Duration: 20 sec. !!!
MyClassBList.ensureObjects; // Duration: 2 sec.
Why is the time difference so large??
I obserbved the behaviour in SQL Server Profiler. For each
EnsureObjects were 4 SELECTs executed: 250 IDs per portion. Execution
time was apparently not the problem, but pauses between SELECTs were
drastically longer for ClassA. I can't explain it myself.
/Efim
|
I can think of two possibilities, either there is a lot more data in
the A objects that the B objects, or else your database behaves
significantly worse for a larger table (index to big to fit into
internal cache?). However, the latter case should show up in the
execution time, so I would bet on the data size.
Have you looked at how much CPU time is spent in the Bold process in
the two cases?
--
Jan Norden
Architect, ECO Team |
|
| Back to top |
|
|
Efim Mett
Guest
|
| Posted: Fri Feb 02, 2007 8:15 pm Post subject: Re: ensureObjects: why so? |
|
|
Hi Jan,
| Quote: | 1. ClassA: has 5,5 Mio persistent instances.
- Attr1: Currency |
- Attr2: Date
- Attr3: Boolean
- Role1: *----1 2 Instances of the class on the other end
- Role2: *----1 100 Instances of the class on the other end
- Role3: *----1 20000 instances of the class on the other end
| Quote: | 2. ClassB: has 0,5 Mio persistent instances
|
- Attr1: Float
- Attr2: Date
- Attr3: String
- Role1: *----1 250 Instances of the class on the other end
- Role2: *----1 2700 Instances of the class on the other end
- Role3: *----1 20000 instances of the class on the other end
- Role4: *----1 13500 Instances of the class on the other end
- Role5: *----1 100 Instances of the class on the other end
- Role6: *----1 30 Instances of the class on the other end
- Role7: *----1 2 Instances of the class on the other end
All beforementioned members are persistent
As you see ClassB has obviousely significantly more data. I would bet for
your assumption 1. I could also observe if it runs on a machine with more
free RAM and faster CPU the both durations are halved, but the ratio 10:1
still remains. That is what I can't explain. It seems the only reason is the
number of records of a table.
/Efim |
|
| Back to top |
|
|
Efim Mett
Guest
|
| Posted: Sun Feb 04, 2007 1:32 am Post subject: Re: ensureObjects: why so? |
|
|
I have found the reason but am not glad about it :-)
TClassA.AfterConstruction
begin
TransientAttribute1 := True;
end;
MyClassAList.ensureObjects invokes multiple calls of
TClassA.ReceiveQueryFromOwned, TClassA.ReceiveEventFromOwned and
TClassX.ReceiveQueryFromOwned, where TClassX is a class on the other end of
an association TClassA * --------- 1 TClassX.
No query/event is really handled though, but these calls alone lead to 10
time worse performance.
I'm not glad as:
1) It's extremely difficult to find such things. I added TransientAttribute1
a long time after TClassA has being implemented. How can one foresee it?
2) It's not always possible to avoid such things. I was simply lucky in
this case to change semantic of TransientAttribute1 to 180° and to avoid
AfterConstruction at all.
BTW I suppose these damages are known to Bold/ECO Team and this is one of
the reasons why business event handling is implemented in ECO on the other
way.
/Efim |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
