Thoughts on agile software development
This article on performance was not actually intended to be a multi-part article. But if you take a closer look at your own code through performance glasses, you will quickly discover further bottlenecks. In this case, it’s an unclean modeling that FreshMarker has been carrying around since its early days. This article is about how this affects the performance of the template engine.
In addition to the expressiveness of the template, the number of supported data types and functions and the expandability, performance is a decisive criterion for a template engine. FreshMarker only evaluates the template output at runtime, so although the template engine is very flexible, it cannot compete with those that evaluate the templates at compile time. For historical reasons, FreshMarker also has no upfront type information about the data used, so some optimization options are not available.
The blog posts on the FreshMarker template engine pursue several goals. On the one hand, the posts should of course entertain their readers. On the other hand, they also serve me to focus and document my ideas on various aspects of the implementation. One very interesting topic in this post is the management of variables within the Template Engine.
The FreshMarker Plug-In Mechanism was one of the first features to be realized for the template engine. The idea behind it was simple. With a proper plug-in mechanism, a new feature can be easily realized and integrated and if it fits the core functionality, it stays in FreshMarker. Otherwise it becomes an independent plug-in. This is how FreshMarker File, FreshMarker Money and FreshMarker Random were created. It also created the internal FreshMarker support for Version, Locale, Year, MonthYear, MonthDay, Duration, Period and some other classes.
In the first article on static FreshMarker templates, some basic thoughts were put on paper. This article is intended to set a first milestone on the way to supporting much faster templates than before. As a nice side effect of this initial work, a pretty printer for FreshMarker templates will be created.
The template engine FreshMarker occupies a middle position in terms of processing speed for the benchmark displayed on the FreshMarker project page. In line with the concept of a dynamic, expandable engine, a noticeable acceleration of processing is not to be expected. The question therefore arises as to which concept can be thrown overboard in order to significantly increase speed.
It’s not that often that a design pattern really blows my mind anymore, but recently I discovered the Passage of Time Pattern by Mathias Verraes. This pattern describes how to deal with time-dependent processes in event-based systems. What makes this pattern stand out is its elegance and simplicity.
FreshMarker started as an academic project. The main aim was to show how a template engine can be created. At some point, however, the question arose as to how fast the template engine actually is. To be honest, it has been slow so far. But first things first.
A Java developer always likes to look into the JDK, like a magician in his old tomes, to see if there is an unknown spell, er method, with which he can improve his source code. In fact, Java 21 has introduced a lot of new methods that make everyday life a little easier.
Im ersten Beitrag zum Whitespace Handling wurde eine einfache Implementierung vorgestellt, die überflüssige Whitespaces entfernt. In diesem Beitrag soll die Implementierung verbessert werden.