Re: [Hibernate] some performnace metric for the dirty check during hibernate flush.
I should also point out that 0.13ms per object is an
absolute best possible case for the database access.
This is reading straight out of Oracle's cache on a
local machine, with no concurrent threads. In a real
system, the database access would be MUCH slower than
that!
Gavin King wrote:
Listen, I really don't have time to waste explaining to
you how to do proper benchmarks in a Hotspot-style JVM!
But, for a start, any tests _not_ done in a loop are
absolutely meaningless!
In my *much* more scientific tests, I find that the flush time per object
is about 0.01ms (about 1/7th of what you are claiming, which is already
much less than you were claiming before). Now, this can be affected by
the size of the actual objects we are talking about but your numbers
still
seem high.
Now, lets get back to reality.
For the objects I mentioned above, the actual cost of loading them
from the database in the first place is about 0.13ms per object on
a local Oracle database . So this falls _well_ within our claimed <10%
overhead.
OTOH, for nontrivial problems, the performance optimizations that
Hibernate can make, which are very difficult to make in handcoded
JDBC, can save you _orders_of_magnitude_ in some transactions!
Gavin.
jiesheng zhang wrote:
Hi, I once suspect that hibernate take too much time in
doing dirty check during session flush. However Gavin
king and other hibernate-user disagreed with me.
I did a simple performance testing to verify the dirty
check performance.
My conslusion is that the performance is not so good
if there are many objects in session. If a session has
around 1000 objects in memory, only will the dirty
check take about 200 million second. For detailed
performance metrics, see the table below.
The structure of my testing object is very simple. One
thing I am not sure is whether the dirty checking
algorithm is related to object structure or not. If it
is, the dirty check in reality will take more time.
My testing case is attached.
---test logic
1. load some (n) number of objects in memory.
2. begin tranaction.
3. // do not do anything here.
4. commit.
Then calculate the time consumed from step 2 and 4.
test code -
List ps=new ArrayList(10010);
for (int i=1000; i<2100; i++)
{
Parent p1=(Parent)session.load(Parent.class, new
Long(i));
p1.getValues().size();
}
long startTime=System.currentTimeMillis();
Transaction tx=session.beginTransaction();
tx.commit();
long endTime=System.currentTimeMillis();
System.out.println("total time(in
ms):"+(endTime-startTime));
-The performance metics-
objects in memorytime (in ms) for dirty check (3
experiments)
1741, 751,821
2000200, 230, 230
1000201, 191, 190,
10030, 30, 30
110, 10, 10
jason
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] some performnace metric for the dirty check during hibernate flush.
Listen, I really don't have time to waste explaining to
you how to do proper benchmarks in a Hotspot-style JVM!
But, for a start, any tests _not_ done in a loop are
absolutely meaningless!
In my *much* more scientific tests, I find that the flush time per object
is about 0.01ms (about 1/7th of what you are claiming, which is already
much less than you were claiming before). Now, this can be affected by
the size of the actual objects we are talking about but your numbers still
seem high.
Now, lets get back to reality.
For the objects I mentioned above, the actual cost of loading them
from the database in the first place is about 0.13ms per object on
a local Oracle database . So this falls _well_ within our claimed <10%
overhead.
OTOH, for nontrivial problems, the performance optimizations that
Hibernate can make, which are very difficult to make in handcoded
JDBC, can save you _orders_of_magnitude_ in some transactions!
Gavin.
jiesheng zhang wrote:
Hi,
I once suspect that hibernate take too much time in
doing dirty check during session flush. However Gavin
king and other hibernate-user disagreed with me.
I did a simple performance testing to verify the dirty
check performance.
My conslusion is that the performance is not so good
if there are many objects in session. If a session has
around 1000 objects in memory, only will the dirty
check take about 200 million second. For detailed
performance metrics, see the table below.
The structure of my testing object is very simple. One
thing I am not sure is whether the dirty checking
algorithm is related to object structure or not. If it
is, the dirty check in reality will take more time.
My testing case is attached.
---test logic
1. load some (n) number of objects in memory.
2. begin tranaction.
3. // do not do anything here.
4. commit.
Then calculate the time consumed from step 2 and 4.
test code -
List ps=new ArrayList(10010);
for (int i=1000; i<2100; i++)
{
Parent p1=(Parent)session.load(Parent.class, new
Long(i));
p1.getValues().size();
}
long startTime=System.currentTimeMillis();
Transaction tx=session.beginTransaction();
tx.commit();
long endTime=System.currentTimeMillis();
System.out.println("total time(in
ms):"+(endTime-startTime));
-The performance metics-
objects in memory time (in ms) for dirty check (3
experiments)
1 741, 751,821
2000200, 230, 230
1000201, 191, 190,
100 30, 30, 30
1 10, 10, 10
jason
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] some performnace metric for the dirty check during hibernate flush.
At 02:29 AM 9/16/2003 -0700, jiesheng zhang wrote:
---test logic
1. load some (n) number of objects in memory.
2. begin tranaction.
3. // do not do anything here.
4. commit.
Then calculate the time consumed from step 2 and 4.
test code -
List ps=new ArrayList(10010);
for (int i=1000; i<2100; i++)
{
Parent p1=(Parent)session.load(Parent.class, new
Long(i));
p1.getValues().size();
}
long startTime=System.currentTimeMillis();
Transaction tx=session.beginTransaction();
tx.commit();
long endTime=System.currentTimeMillis();
System.out.println("total time(in
ms):"+(endTime-startTime));
-The performance metics-
objects in memory time (in ms) for dirty check (3
experiments)
1 741, 751,821
2000200, 230, 230
1000201, 191, 190,
100 30, 30, 30
1 10, 10, 10
jason
This is a lot better than your original statements to the list. You were
originally quoting 1 second per object for transaction commit. Now you are
doing 1 in less than a second. Also, you would need to test to see how
long just the .beginTransaction() and .commit() methods are taking,
disregarding a dirty check. In other words, don't load any objects. Just do
the last part of your code and see what you get.
Patrick
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] some performnace metric for the dirty check during hibernate flush.
Hi,
I once suspect that hibernate take too much time in
doing dirty check during session flush. However Gavin
king and other hibernate-user disagreed with me.
I did a simple performance testing to verify the dirty
check performance.
My conslusion is that the performance is not so good
if there are many objects in session. If a session has
around 1000 objects in memory, only will the dirty
check take about 200 million second. For detailed
performance metrics, see the table below.
The structure of my testing object is very simple. One
thing I am not sure is whether the dirty checking
algorithm is related to object structure or not. If it
is, the dirty check in reality will take more time.
My testing case is attached.
---test logic
1. load some (n) number of objects in memory.
2. begin tranaction.
3. // do not do anything here.
4. commit.
Then calculate the time consumed from step 2 and 4.
test code -
List ps=new ArrayList(10010);
for (int i=1000; i<2100; i++)
{
Parent p1=(Parent)session.load(Parent.class, new
Long(i));
p1.getValues().size();
}
long startTime=System.currentTimeMillis();
Transaction tx=session.beginTransaction();
tx.commit();
long endTime=System.currentTimeMillis();
System.out.println("total time(in
ms):"+(endTime-startTime));
-The performance metics-
objects in memory time (in ms) for dirty check (3
experiments)
1 741, 751,821
2000200, 230, 230
1000201, 191, 190,
100 30, 30, 30
1 10, 10, 10
jason
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
src.zip
Description: src.zip
