Type of enhancement
runtime performance
Enhancement description
Currently, each handler for a property read (and writes) the files again. Doing this only ones should speed up ecformat due to fewer accesses to the disc. However, a primitive try to switch simply to pass the content of the files as bytes instead of reading them again from path, slow down ecformat. I tried this with commit 4177b0fcdd, but this makes the performance worse. Therefore, I reverted this changes with commit a786f51f32. (Performance tests took place inside an Alpine Linux container with a musl build of ecformat.)
It looks like that ecformat already uses 100 % of one CPU core in most of the time in the test scenarios. Therefore, this issue should be considered after issue #15.
Resources
- Example of a profiler for Rust applications: flamegraph
### Type of enhancement
runtime performance
### Enhancement description
Currently, each handler for a property read (and writes) the files again. Doing this only ones should speed up ecformat due to fewer accesses to the disc. However, a primitive try to switch simply to pass the content of the files as bytes instead of reading them again from path, slow down ecformat. I tried this with commit 4177b0fcdd270e891600eb07146cb340d2b1e615, but this makes the performance worse. Therefore, I reverted this changes with commit a786f51f32612b9191248fee259309a3388589e2. (Performance tests took place inside an Alpine Linux container with a musl build of ecformat.)
It looks like that ecformat already uses 100 % of one CPU core in most of the time in the test scenarios. Therefore, this issue should be considered after issue #15.
### Resources
- Example of a profiler for Rust applications: [flamegraph](https://crates.io/crates/flamegraph)