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