-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
draft: Perf: optimize petri net replay #445
base: release
Are you sure you want to change the base?
draft: Perf: optimize petri net replay #445
Conversation
Please notice that this is technically not stable across runs since the hash() function has some seed. However, that was previously also the case, because the hash of a place uses the id() method
@Javert899 Is there anything missing on this PR? I took a look at the Dijkstra less memory method and it should be possible to rewrite the compiled semantics class to use some of the techniques there. This should make the alignment code cleaner as well as exposing this efficient representation to the end user |
@Javert899 any progress here? I guess now the code is outdated |
@EduardoGoulart1 we will integrate more when our contribution level agreement will be approved by the Fraunhofer. Until then, we will try to identify specific contributions with high impact and integrate giving due credits |
@fit-alessandro-berti Since there has been no action on this PR, do you think we should close it? |
This was worked on during the Celonis Impact Day on the 29th of September 2023
This PR suggests a few changes to the Petri net semantics class to optimize the Petri net replay. The changes go from less to more radical, so it's up for discussion about which changes should be accepted. The optimizations is guided by the benchmarks. Given a Petri net (the 5 added), it measures the total runtime to compute the reachable markings of the Petri net. The results can be found below (runtime in seconds):
If you ask me, only slots are not worth the trouble, because it will potentially break existing code (if the users have been misusing the class). The change from counter to dict would also require some rework before deploying. In the end, we would end up reimplementing the Counter Python class, but that is alright because the counter class is just very slow. The usage of place IDs instead of places for the markings could be hidden behind some nice abstractions (example: a "CompiledMarking" class)
Attention Do not merge the PR with the Petri nets (and the benchmark script)