XES Lite Resource-friendly event logs in ProM

XES Lite
Resource-friendly event logs in ProM
Felix Mannhardt <[email protected]>
OpenXES Naïve
2
OpenXES Buffered
3
Problem(s)
17 MB log  >2 GB heap space
or
*
17 MB log  80 s load time
4
OpenXES naïve implementation
5
What is wrong?
• 12 million XAttributeMapLazyImpl instances
• 17 million String instances
6
XES Lite: 2 flavors
Memory-based
=
Unbuffered
Disk-based
=
Buffered
7
Unbuffered &
Lightweight Implementation
Saving 410 MB on
String instances
Saving 288 MB on
“Lazy” instances
8
How does it work?
• Flyweight pattern, here String interning
• New implementation XFactoryLiteImpl:
– Interns the key’s of all XAttributes
– Interns the values of concept:name ,
lifecycle:transition, org:resource for XEvents
9
How does it work? (cont.)
• Avoiding the XAttributeMapLazyImpl
– Don’t create the default instance
– User needs to call setAttributes explicity to use
attributes on attributes
• This change may break existing code!
10
Buffered
-based
Alternative to the OpenXES buffered implementation using
MapDB as storage backend.
MapDB provides concurrent Maps, Sets and Queues backed
by disk storage or off-heap memory. It is a fast and easy to use
embedded Java database engine.
• Drop-in replacement for ConcurrentTreeMap and
ConcurrentHashMap.
• Outstanding performance comparable to low-level native
DBs (TokyoCabinet, LevelDB)
• Instance cache to minimise deserialization overhead
11
Conclusion
• Use Lightweight as “Standard”
• Use MapDB if free memory is really important
12
Questions?
Try out:
XESLite package
More infos on my blog:
fmannhardt.de
13