Hi,
one of the reasons for the bad performance of the first
implementation is the use of Thread.sleep(1).
The spec only gurantees a delay for AT LEAST the given period. But
most VM implementations of Thread.sleep are working only
with an accuracy of 10ms... depending on the systems settings and
according to our Sun consultant it is even worse on Sun machines (up
to 50ms).
Here's a backtrace of our testcase running on a Sun SPARC machine
(this shows that the VM is mostly in Thread.sleep(), so the CPU is
actually doing nothing... no load)
Full thread dump Java HotSpot(TM) Server VM (1.5.0_04-b05 mixed mode):
"FileListener-XML Import" daemon prio=10 tid=0x008bfd08 nid=0x18
waiting on
condition [0xd1f7f000..0xd1f7fa90]
at java.lang.Thread.sleep(Native Method)
at
org.objectstyle.cayenne.util.IDUtil.pseudoUniqueByteSequence16
(IDUtil.java:152)
- locked <0xf59aa7e0> (a java.security.MessageDigest$Delegate)
at org.objectstyle.cayenne.ObjectId.<init>(ObjectId.java:120)
at
org.objectstyle.cayenne.access.DataContext.registerNewObjectWithEntity
(DataContext.java:882)
at
org.objectstyle.cayenne.access.DataContext.createAndRegisterNewObject
(DataContext.java:
[...]
Have you tried the RMI implementation to generate UUIDs? Maybe
someone here does know about another very fast UUID algorithm... as
this is used for every object creation...
- Ingo.
Am 03.02.2006 um 01:00 schrieb Andrus Adamchik:
> BTW, I just checked in a faster implementation of IDUtil that does
> not attempt to produce a "secure" ID by creating an MD5 digest.
> Also the new temp ID is just 8 bytes, not 16. Supposedly the new
> algorithm makes IDs easier to guess, but in this case it is
> irrelevant, as such ids are substituted with another value on commit.
>
> The new version of ObjectId constructor is 15-20 times faster than
> M10. But of course there maybe other inefficiencies downstream (we
> may need to profile ObjectId HashMap put/get performance - this is
> probably more important).
>
> Andrus
>
>
> On Feb 2, 2006, at 12:20 PM, Florian.Esk..i-de.com wrote:
>
>> To show the problem we produce a sample code. The code needs for 1000
>> objects with
>>
>> cayenne 1.1 3562 milliseconds
>> and
>> cayenne 1.2M10 17781 milliseconds
>
>> Profiling of the application show us that in version 1.2 most of the
>> creation time is spent inside
>> org.objectstyle.cayenne.util.IDUtil.pseudoUniqueByteSequence16()
>
>
>
>
This archive was generated by hypermail 2.0.0 : Sun Feb 05 2006 - 16:13:12 EST