search

rapidprom / source

Source code of RapidProM v3, will be renamed to rapidprom-source-3
1 stars 1 forks source link

Investigate why the precision calculation takes a long time (sometimes) #5

Closed joosbuijs closed 8 years ago

joosbuijs commented 8 years ago

Calculating the precision, given an alignment, sometimes takes a long time. It would be good to see where this time is spend (in the plug-in or in RapidProM) and then of course try to fix it.

TaXxER commented 8 years ago

I did a bit of investigation into this yesterday. RapidMiner now uses the measureConformanceAssumingCorrectAlignment method from org.processmining.plugins.pnalignanalysis.conformance.AlignmentPrecGen for the precision calculation. On some models and logs this can indeed be very computationally expensive, but I found this to be the case also in ProM, so its is not a RapidProM problem. The Yourkit profiler shows that it spends almost all its time in the while loop of line 353 of the calcEnabledModel method, where it calculates all previous markings in the net from which a given marking can be reached by firing silent transitions. It seems like this problem arises when there are many parallel parts in parallel that contain a silent transition.

The ETC conformance plugin of Jorge Munoz-Gama also supports calculating (escaping edges) precision based on an XLog, Petrinet, and PNRepResult. I've applied this plugin successfully on logs/nets where the other method mentioned above is computationally very slow. A good solution could be to replace the backend of the precision operator with the ETC conformance version instead, or, maybe create two separate operators. See method checkMultiETCAlign1 in package org.processmining.plugins.multietc.plugins

s-j-v-zelst commented 8 years ago

moved to rapidprom-source, please follow from there.