Home » Support » Forum » What algorithm in find()

What algorithm in find()

#1

I test the time cost for find(), obtain a linear complexity with the following codes:

  int iBlock = 0x10000;
  for (int i = 1; i <= 3*iBlock; i++) {
   trans.begin();
   Node o = new Node();
   Node p = em.find(Node.class, i/3);
   if (null==p) System.out.printf("Node %d has no parent.%n", i);
   o.setParent( p );
   em.persist(o);
   trans.commit();
   if ((i & 0xFF)==0){
    end = System.currentTimeMillis();
    System.out.printf("%d @ %s %n",i, (end-start)/1000f);
   }
  }

The time cost of each 256 commits changed from 0.343 to 59.344 seconds, the graph attached shows a linear complexity, i.e. O(n). So what algorithm in find()? Can it improved to O(log(n)) complexity?

Institute of Computer Technologies
image/gif iconObjectDB_find.GIF (9.00KB)
Graph of Time cost in find()
#2

Slow commit might be the result of not using enhancement and not calling clear.

Please check this forum thread that might be relevant.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#3

  I use your codes to commit, the time cost in the attachment shows a O(n) complexity. Why? The cost of insertion is subjected to the number of objects in database?

  When the 1,000,000 objects being persisted, I record the time cost every 0xFFF objects, the time cost changes from 0.2 seconds to 1.1 seconds.

Institute of Computer Technologies
#4

Ok, I do the same test in MySQL server, the insertion complexity is still O(n).

see the attachment.

Institute of Computer Technologies
#5

This might be the same problem - transactions that become larger and larger because of not using clear and classes that are not enhanced.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#6

Hi, clear() seems helpful in reducing the cost.

If the cache works, then the more managed entities the better, aren't they?

If the managed entities are cleared, then the cache looks useless, right?

How do I keep a defined size cache, say 512MB, for frequent visiting entities to avoid the latency time in TCP/IP?

TIA

Institute of Computer Technologies
#7

When classes are not enhanced the persistence context cache slows commit / flush, since every entity object in that cache has to be checked against an old image to identify updates automatically.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#8

Do you mean the cache in JPA is exactly a doll? If applications have to maintain the clear(), then what threshold is the best to set a clear()?

TIA

Institute of Computer Technologies
#9

The cache is useful - but not when persisting large number of objects, especially if classes are not enhanced. If the classes are enhanced - the effect of calling clear is small.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply

To post a reply and/or subscribe to update notifications - please login