Dear Hana,
Thank you for your interest in VIATRA.
1.
About your earlier question regarding the omission of parameters from the big pattern: while I am not familiar with your exact transformation needs, usually traceability connections between the source and target model
are (almost) one-to-one. This means whether or not they are included in the pattern *should* make little difference in performance. At least that is my expectation. But ultimately, only actual measurements can tell the truth. (Note that if you have
one source/destination element traced to many such “sourceref”/”destinationref” elements, then what I said before does not apply; they may really make a difference in that case)
2.
I have taken a look at the results.txt report that you have attached.
I see that you received an OutOfMemory error… how many gigabytes of Java heap space did you allow the JVM process to use (-Xmx command line switch)?
Remember that if you use the incremental pattern matcher of Viatra, it will maintain both the query results as well as internal auxiliary caches, both of which will take up additional memory on top of the memory required
to store the model itself. You have to make sure that Viatra has plenty of heap space to go around; running it with whatever default the JVM or Eclipse chooses is often not enough.
3.
Now for the actual query profiling results.
Unfortunately, they are not very useful right now. You can see that the whole thing together consumes less than 3 MB. I find it unlikely that 3MB is enough to run you out of memory. However, this low memory usage is probably
very uncharacteristic of your actual transformation solutions. The tables tells you that most of your patterns have 0 matches, while I assume in a typical execution each pattern would have many matches.
Zoltán forgot to mention that in order to get out any value from the query profiler [1], you must provide it with an EMF instance model that is a meaningful workload. Try to find a state of your model where each of your
Viatra patterns would have a typical or higher-than typical amount of matches. If necessary, you can use different instance models / states to best exercise different patterns.
4.
Just a side remark: in addition to the query profiling tool [1] linked before there is also RelativeQueryPerformanceTest [2] which separates the memory cost of a Viatra pattern itself from the underlying cost of
other patterns referenced using „find”.
5.
Also, I took a *very* cursory look at your repo (specifically at [3]), and found that you seem to have two VQL files, one with pattern called find_*, the other with copy_*, however these seem to be the same patterns,
just under different names? Or at least I did not manage to find any difference by a single glance.
Why have two duplicate copies of the same pattern? Why not just use the same pattern twice? If you have two different pattern definitions with the same content, and you use both of them over the same model at the same
time, you pay twice the memory cost!
Good luck with your paper!
Best,
Gábor Bergmann
[2]
https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/tests/org.eclipse.viatra.query.testing.core/src/org/eclipse/viatra/query/testing/core/RelativeQueryPerformanceTest.xtend
[3]
https://gitlab.telecom-paris.fr/mbe-tools/mt-bench-public/-/tree/master/viatra/fr.tpt.mem4csd.mtbench.aadl2aadl.viatra/src/fr/tpt/mem4csd/mtbench/aadl2aadl/viatra
sorry, but for clarification, I would like to ask whether you selected these patterns by intuition or by some kind of measurements. I am asking this as the Rete network structure used by VIATRA has some very unusual memory characteristics
(e.g. a pattern with more constraints might be more efficient to evaluate than another one with a clear subset of parameters). The measurements in the QueryPerformanceTests (point 2 of my original mail) would provide that information.
OK, this is the Performance test results:
pattern, sequence, matches count, heap before (kb), heap after (kb), used heap (kb), elapsed (ms)
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_component, 10, 0, 39227, 39354, 127, 17
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_connectionref, 9, 0, 39226, 39342, 116, 14
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_feature, 6, 0, 39224, 39631, 407, 75
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_otherconnection, 3, 0, 39214, 39478, 264, 74
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_otherconnection_system, 2, 0, 39207, 39496, 289, 100
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_portconnection_process, 1, 0, 39198, 39702, 504, 209
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_portconnection_system, 5, 0, 39224, 39976, 752, 281
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_subcomponent, 4, 0, 39223, 39415, 192, 29
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.find_system, 8, 1, 39226, 39272, 46, 5
fr.tpt.mem4csd.mtbench.aadl2aadl.viatra.is_in_trace, 7, 0, 39225, 39290, 65, 8
And you can find the total analysis in the attached file.
Furthermore, it is unclear to me how the modified pattern relates to the issue (some more detail would be helpful).
Well, I thought that the problem is caused by the number of parameters, so my idea was to eliminate some parameters in the find_otherconnection_system/find_otherconnection_process patterns.
Hana.
|
