"Dynamic, incremental, multi-level cache system"
This means for example that:
- The cache is built on-demand, or at the first request of any given element, meaning you won't have redundant cache content to take space in your file system. This also contributes towards server load balancing.
- There is a central cache database registry, where cached items are tagged as in or out of synch with the actual data, and regenerated accordingly when needed.
- Cache-elements for the different post etc. formats are automatically built to reflect the way your site layouts are configured in the Builder.
- There is also a pre-cache-parsing combining templates with language packs, that further cuts down the memory and CPU imprint for creating cached elements when they are requested.
- Currently the cache will be stored on the file system. A MySQL-based cache version will become available as an option for those with more database storage space.
More information to come on all this as we near the release.
Class dependency optimizations
This means that:
- The amount of code that's loaded into the memory is minimized through careful isolation of different areas of the code (generally structured into classes), as every bit of code from our framework is loaded only once, and only when required, and is buffered into memory in the event of a similar need further on as the page units ("boxes") are created.
- A similar isolation and optimization of templates and languages has already been done. (Typically applications like this have a good deal of code overhead that makes them bloated, hogging huge amounts of memory.)
- This approach also makes modifications of all varieties much easier, because everything you may need to change is found exactly where it's meant to be, and there are no stray bits of language, templates, or code, that you would also need to change to get your customizations done.
If the above may come across as a tad bit cryptic. the bottom line is that Wiccle rocks when it comes to performance and ease of customization.
