Functional programming does not, by itself, imply performance penalty. There are however some reasons for performance problems that are related to specific languages. For example, Java is not recursive. It is supposed to be, but as it doesn't do Tail Call Elimination, it is limited by the size of the stack. You can increase the size of the stack, but this increased size will apply to all threads, which means a waste of memory because not all threads will need this increased size. We can solve this problem by running recursive call on the heap instead of on the stack, through the use of trampolining. One chapter of my book is dedicated to this technique. But since one object will be created for each step, it is a bit slower. It has however never been a problem for me although I use it heavily in production code.
Before Java 8, using high order functions implied creating objects, generally instances of anonymous classes. This could have a very minimal cost, but it could have a bigger one if used in loops. With Java 8 lambdas, anonymous classes no longer need to be created, although you can still force Java to create them (sometimes inadvertently).
The main reason for performance impact is using the wrong data structures. A singly linked list is much faster than an ArrayList for insertion and retrieval on one side. It is however much slower for the same operation on the other side. It is also much slower for indexed access, but much faster for multiple deletions on huge lists. But you can use other structures for indexed access (Vector) or for double end access (Double Ended Queue). But it is true that sometimes, you need a structure that is good enough for multiple types of access and may find the ArrayList more efficient. But you have to put this in balance with the numerous benefits of being immutable.
While on about creating instances of anonymous classes, does the use of λs instead reduce the potential security hazard of synthetic accessor methods?
posted 3 years ago
With lambdas, there is no anonymous classes, so there is no risk related to synthetic methods to private members as it was the case with anonymous classes. The main consequence is that the this reference in a lambda refers to the enclosing class. This dos not suppress all such problems, such as synthetic method created for members of parameterized types, but this is not related to lambdas, but more generally to leaking the this reference. Note however that in functional programming, member variables are always made final, so this would in any case be much less of a problem.
Montana has cold dark nights. Perfect for the heat from incandescent light. Tiny ad: