> Thanks for advice, will try that next. :)
But, since this heap-dump is just a snapshot in time,
it will show only 'leaky-like' problems. So if the
underlying problem is, that there are a lot of very short
living objects, it probably won't help you.
Cheers,
Georg
Stanislav Muhametsin wrote:
Quoting Georg Ragaller <[email protected]>:
For memory profiling I successfully used http://www.eclipse.org/mat/ .
Simply run your test outside eclipse, make a heap-dump (I prefer
JConsole) and analyze the heap-dump after the application has finished.
MAT offers a quite intelligent mechanism to give you hints about the
source of the evil.
Cheers,
Georg
Thanks for advice, will try that next. :)
I tried to stack all removing in the
RdfIndexingService.RdfEntityIndexerMixin , so that there would be always
_at most_ one invocation of connection.clear(Resource... contexts) per
notifyChanges method. Here are the results:
.18.2.2010 12:54:01
org.qi4j.entitystore.prefs.PreferencesEntityStoreMixin activate
INFO: Preferences store:/Application
17717 [main] INFO org.qi4j.index.rdf.newtests.RDFPerformanceTest - Time
to create 200 entities (ms): 1520
21787 [main] INFO org.qi4j.index.rdf.newtests.RDFPerformanceTest - Time
to complete creation uow (ms): 4070
18.2.2010 12:54:10 org.qi4j.index.rdf.query.internal.RdfQueryParserImpl
getQuery
<snip query>
26655 [main] INFO org.qi4j.index.rdf.newtests.RDFPerformanceTest - Time
to delete 200 entities (ms): 4868
97731 [main] INFO org.qi4j.index.rdf.newtests.RDFPerformanceTest - time
to complete deletion uow (ms): 71076
Time: 97,164
OK (1 test)
Some improvement proportionally-wise, however it might go to variation
of profiling results. Gotta investigate more. :)
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
