la-yumba / functional-csharp-code

Code samples for Functional Programming in C#

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Performance of the library

dmitriifilonenko opened this issue · comments

Hi!

It's basically a question, not an issue. And sorry for asking it here. I just didn't find any other propper place for asking, like author's site or forum, etc.
I'm reading the book. And I'm very much excited about it. Very eager to use the shown technics in my own code.
But I'm a bit worried about performance. Some niceties shown in the book (and hence availbale in the library) definitely comes for a cost of an overhead either in performance or memory consumption. I'm currently on the chapter 4, and I've found at least two such questionable cases.

  1. Struct Option. For the lack of some constructions (like a record) in C#, this type is implemented with some workarounds like wrapping given value to an instance of another struct, which in addition has an extra member of bool (overhead both in memory and in performance due to initialization code).

  2. ForEach pattern. In order to make it work with Actions, it converts Action to Func and creates an IEnumerable kind of implicitely for a client who uses the library. So when calling ForEach on an array of a million elements, it will additionally create yet another array of million elements... Well, most likely it will be short living array. But such an immediate burst in memory consumption can be still very sensitive.

Have any performance tests been run on the library which would compare performance impact of library to a similar 'traditional' code? I mean 'traditional' in a sense that it does the same but looks maybe uglier, 'dishonest', etc.

Thank you!

Hi Dimitri,
thanks for your question. As explained in the introduction to the book, the intent of the library is didactic, so performance is not high on my list. About your more specific questions:

  1. With Option, one way of looking at it is that you're essentially trading stack space (the additional overhead of the boolean accompanying the value) with code complexity ("if x == null..." everywhere), which I think we can all agree is a worthwhile tradeoff in terms of maintainability and therefore productivity. Of course, I would never advocate using Option everywhere - only when there is the possibility that a value is not available; so using the additional bool correctly models the domain and is in fact the most effective way to do so.
  2. With ForEach, you're doing side effects, so if you need to do one million side effects, then the overhead of the created IEnumerable is probably the least of your worries! Also, IEnumerable does not allocate an array - they're lazy, so it's not creating a million-record array as you suggest.