paldepind

How can List be faster than native arrays?

Sun, 06 May 2018 14:25:45 +0100

List is an extremely fast immutable list that can be used as an alternative to native JavaScript arrays. Since List is immutable it is made for functional programming. For this use case it is often much faster than native JavaScript arrays and libraries that operate on arrays like Lodash and Ramda.

Jeremy Likness recently tweeted about List (thanks a lot). One of the things he mentioned was the claim that List is faster than arrays. Several people responded with a healthy skepticism to this statement. How can something be faster than arrays which are native to JavaScript and highly optimized by the JavaScript engines? The short answer is that by exploiting immutability List can avoid a lot of unnececarry copying through structural sharing. This blog post will go into more detail and show how structural sharing leads to huge improvements in performance.

The problem with arrays

In functional programming, we never mutate or change our data-structures. Instead, all operations on data-structures that needs to change something must return a new version without modifying the old one. An example of this is the concat method on arrays. The code arrayA.concat(arrayB) changes neither arrayA nor arrayB. It returns a brand new array.

Arrays are stored in memory as a consequetive sequence of bits.

Therefore, when a pure function operates on arrays the only thing it can do in order to return a new array is to copy the entire array. For instance, to append a single element to a list by using concat or Ramda’s append the entire array that is being appended to must be copied. As another example, to remove the first element of an array one can write array.slice(1), use the function _.initial from Lodash, or R.init from Ramda. All of these functions make a copy of the entire slice. If the array is 1000 elements long the code will construct a brand new array of length 999.

When doing functional programming with arrays a lot of time is wasted copying arrays all the time. This not only makes our code slower, it also gives the garbage collector extra work because it has to free all the memory again. We pay twice.

How List solves the problem

List is an implementation of an immutable data-structure called relaxed radix balanced trees. Like most immutable data-structures it uses a technique called structural sharing to avoid the unnecessary copying we saw with arrays. Internally a sequence of elements is stored by List in a format that looks a bit like this.

One way of looking at the above is that List stores elements in several small chunks. Whenever we need to create a new list we can reuse all the chunks that didn’t change. This type of reusing is structural sharing. Arrays, on the other hand, store everything in one big chunk so it’s not possible to use share anything when changing an array.

If we appended an element to the above list we would get a new list that, internally, looked something like this.

The dashed boxes represent the new list. Note how everything in the old list is reused in the new list. This is one part of why List can perform so well. Appending an element to a list takes essentially the same time no matter how large a list we’re appending to. This can be seen in benchmarks.

Appending an element to an array takes more and more time as the array gets larger. For List the time is constant. Appending an element to a list takes the same time on a list of length 10 as it does on a list of length 10.000.

This performance improving technique applies to a wide range of operations. Sharing is useful for things such as changing a single element in a list, inserting elements into a list, concatenating lists, and slicing a list. The graph below compares the performance of slice between List and arrays.

Again, every time we want to change something in an array we must make a copy of the entire array. But, to change something in a list we can reuse large parts that can be shared between the new and the old list.

Another aspect that makes List faster than native arrays is that many methods on native arrays are actually quite slow. This applies to map, filter, reduce, and more. They have a lot of complexity that slows them down. For instance filter must handle sparse arrays and must accommodate for the filtering predicate mutating the array during the filter. These things are required per the JavaScript specification and they slow down native arrays. The graph below shows the performance of filtering a List versus filtering an array.

Caveats

Even though List is very fast across the board no data-structure can be the fastest at everything. There are a few operations where List is slower than native arrays. One of these is random accessing. I.e. accessing arbitrary elements out of order. But, even in the few cases where List is behind native arrays, it is not behind by much.

Another caveat is that some functions in List are slower than arrays for very small lists—even though they scale better to larger lists. This can be seen in the plot of slice above. List’s slice is a lot faster on large lists but for small lists, it is slightly slower. This is something that I’m planning to improve in the future.

Conclusion

By using structural sharing List can implement a lot of operations in a way that is much faster than what is possible with arrays. This means that for most functional use cases using List will be faster than arrays. However, that is only part of the reason why someone may use List. Other benefits, that in many cases are more important, are enforced immutability and the extensive API that List offers.

For more information about List check it out on GitHub. For more extensive benchmarks see the benchmark report.

Behaviors and streams, why both?

Fri, 12 May 2017 14:25:45 +0100

Introduction

Functional reactive programming (FRP) has historically included two different abstractions over time: behavior and stream. Today most FRP and FRP-inspired libraries only have a single abstraction over time. This one abstraction is typically called “stream” or “observable”.

People used to these libraries may wonder: Why do I need both behavior and stream? I’m doing fine with just streams/observables. Asking that is natural. In fact, when I wrote my first FRP library Flyd I only included a single abstraction over time. I thought it was simpler than having two concepts.

However, after digging deeper into FRP I came to see that one loses something very crucial when not making a distinction between behaviors and stream. What exactly that is is not obvious, however. In this blog post, I will try to explain what it is.

What is the difference anyway?

Both behaviors and streams represent things that happen or changes over time. But still, they are very different. Visually this difference looks like this.

Intuitively, a behavior is a value that changes over time. And a stream is something that has occurrences at specific moments in time. A behavior can be seen as a function over time. A stream, on the other hand, is a list of events associated with their time of occurrence.

To figure out whether something is conceptually a behavior or a stream one can simply ask: Does this thing has a “current value” or does it instead have a “last occurrence”? In the first case, it is a behavior and in the later case a stream.

The classic example is the mouse. Its position is a behavior while the clicks of its buttons are streams. Here are a few additional examples:

Sunset is a stream. It doesn’t have a current value but it does have a last occurrence.
The position of the sun is a behavior since it always has a current value.
The height of a tree is a behavior since it has a current value.
Leaves falling off of a tree is a stream—we can tell when a leave last fell off the tree.

As you can see things in the real world are either a behavior or a stream. So it seems natural that our programs should be able to express the difference as well.

How can one get away without both?

Most libraries that only have a single abstraction over time has one that is much more like a stream than like a behavior. They pretty much just lack behavior altogether. Whenever people say things such as “an observable is like a list over time” they are talking about streams. They can’t be talking about a behavior because a behavior is a function over time.

How do they compensate for the lack of behaviors? Well, essentially one just “interprets” a stream as a behavior. The image below illustrates this.

On the left, we see an actual behavior and on the left we see a stream interpreted as a behavior. We simply remember the last occurrence and takes it to be the “current value” of the stream. Some libraries remember event occurrences like this by default while other have a variant of their stream/observable that does. So even though some libraries doesn’t recognize behaviors as a separate thing they still need features to fill in the gap.

The crucial question now is: What are the downsides to only supporting this “fake” behavior? What are the benefits of having an actual behavior separate from streams? Hang tight, because that is what the rest of this blog posts covers.

It is precise and explicit

When programming it is generally good practice to use types that are as precise as possible. For instance, even though we could, in theory, represent all numbers as strings, we don’t. Even when programming in a dynamic language like JavaScript it is a good idea to have an idea about which types of values your variables contain. For instance, you may be thinking things like “this variable is a number” and “this variable is a string”.

Likewise, when programming with FRP it is beneficial to know which things in a program are behaviors and which things in a program are streams. Conceptually these are two different things! Asking yourself whether a certain phenomenon is a behavior or a stream is highly useful. It is a useful mental process that makes you more aware of what exactly you are dealing with. Making a distinction between behavior and streams gives us richer vocabulary. If your program also makes the distinction this richness will translate into programs that are more expressive and precise about they are talking about.

On the other hand, expressing both behaviors and streams with a single abstraction makes it is impossible to make a clear distinction. That can create confusion and inhibit features and performance because two separate concerns are mixed into a single abstraction.

It prevents mistakes

Libraries that makes a distinction between behaviors and streams can prevent many errors from happening.

For instance, a behavior always has a current value. But, streams doesn’t. This means that when a stream is used as a behavior the user will have to remember to supply some initial occurrence to the stream. If the user forgets that, a bug has been introduced.

A library that recognizes behaviors can know exactly when it is dealing with such. When a current value is expected the API will require a behavior. And the API makes it impossible to create behaviors that don’t have an initial value. This completely eliminates errors where initial values are missing.

Another thing we can prevent with explicit behaviors is meaningless operations. There are a bunch of operations that we can apply to a stream that does not make sense on a behavior. Likewise, there are operations that make sense on a behavior but not on a stream. Libraries that can’t tell the difference between behaviors and streams can’t prevent people from carrying out operations that don’t make sense.

As an example, it makes sense to combine two streams by merging their occurrences. Visually it looks like this

However, combining two behaviors in this manner doesn’t make any sense. But still, libraries that don’t support behaviors can’t prevent it. We may end up merging the position of one object with the position of another object. This will a result that no longer makes sense understood as a behavior. This can lead to code that does “shady” or confusing things by exploiting that behaviors are represented as stream.

It is a higher abstraction

Some behaviors have multiple representations as a streams. For instance, these two streams represent the exact same behavior.

Clearly, these “extra” occurrences don’t change the streams meaning as a behavior. But a stream-only library doesn’t know that. Since the library doesn’t have the behavior abstraction but uses streams instead its API necessarily exposes how many occurrences a steam is made of. Even when it’s used as a behavior.

When implementing a behavior, the API can be designed such that “peeking into” the internal representation of a behavior in this manner is impossible. The library knows when the user actually wants to use a behavior. This allows for more optimizations since no implementation details are exposed.

For instance, when implementing behavior with a dependency graph only actual changes in values have to be propagated. As an example of this, let’s say a user writes the following:

const flooredNumberBehavior = numberBehavior.map(Math.floor);

Clearly some changes to numberBehavior won’t lead to a change in flooredNumberBehavior. Maybe an update flows down that changes numberBehavior from 3.5 to 3.8. In this case an implementation of behavior can recognize that nothing changes in flooredNumberBehavior. This allows it to simply stop propagating changes down.

This can lead to substantial improvements to performance as it prevents needles re-computation. To , such an optimization can never be done. Because someone might call a method like scan later that exposes the number of occurrences and not just changes in value.

It allows for infinite resolution behaviors

While the stream interpreted as behavior, we saw above, can represent some behaviors it can’t represent all behaviors. Some behaviors it can only crudely approximate. That is because a behavior can change “infinitely often”. I.e. be continuous. An example of such a behavior is seen below.

To the right, we have an attempt at approximating the behavior with a stream. Clearly, such an approximation is lossy and imprecise.

Being able to represent these types of behaviors with infinite resolution is extremely beneficial. In particular, it is helpful when writing programs that deal with things such as time and motion. Like when implementing animations for instance.

One may think that this problem can be avoided simply by using streams with a resolution that is “good enough”. But the problem is not only related to resolution. It is also a problem about composition.

For instance, let’s say you want to implement an animation with streams. You may think, I’ll just create a stream that has an occurrence for each frame. Clearly, that resolution is good enough. But consider what then happens if you combine two such streams. For instance, you may have an x-coordinate that changes every frame and a y-coordinate that does the same. If you combine those you get a stream that changes twice every frame. That is pretty bad.

With an FRP library that support continuous behaviors that problem does not exist. You’d simply have a behavior for the x-coordinate and one for the y-coordinate. Internally those will be represented in a way that supports infinite resolution. Thus, when you combine them you simply get a third behavior, also of infinite resolution.

The above problem is similar to vector graphics vs. pixel graphics. Vector graphics has infinite resolution. This means that we can, among other things, zoom in and rotate without losing quality. Of course, at some point, a vector image will have to be converted to pixels in order to be displayed on the screen. But such a conversion only happens at the very last step, after we have zoomed and rotated. Similarly, when working with behaviors of infinite resolution all operations on them happens to the internally infinite version. Only for the purpose of showing them on the screen are they converted to a format with the necessary resolution.

Conclusion

We have seen some of the main benefits of recognizing that behaviors and streams are two different things. It may up front seem like having two abstractions is more complex that just one. But it turns out that down the road it makes things much simpler and more powerful. In general, programs that keep separate things separate are easier to understand.

Introducing Jabz

Wed, 04 Jan 2017 14:25:45 +0100

Introduction

Jabz is a new library aimed at implementing powerful abstractions in JavaScript while being as practical as possible. It is hugely inspired by Fantasy Land but is an attempt at achieving something more convenient and with better performance.

Jabz specifies the same abstractions as Fantasy Land. Functor, monad, traversable, etc. Besides specifying these things it is also a library that includes a common set of functions for working with the abstractions, as well as often used implementations.

I initially created Jabz to be a TypeScript implementation of common structures satisfying the Fantasy Land specification, but along the way I had some ideas that warranted a new specification. In this blog post I will explain how Jabz’s specification of these abstractions differ from Fantasy Land’s. I will assume that the reader is familiar with Fantasy Land and the related abstractions.

Jabz can be found on GitHub.

Goals

My overlaying goal was to create a specification and a library that achieved the following properties:

Convenience. Using the abstractions should be as convenient as possible from an end users perspective. Developer ergonomics should be highly valued.
Performance. Inefficient abstractions are useless abstractions. The specification should give implementations the necessary room for creating performant implementation.
Power. The abstractions should be as powerful as can be. That is, they should have as many features and support as many use cases as possible.

To achieve the above, the one thing I traded away was simplicity of specification. Fantasy Land is a simple and elegant specification that only concerns itself with what is strictly essential. Jabz, in comparison, is more voluminous. I do, however, believe the trade-off is worth it.

Below I will describe the major general differences between Jabz and Fantasy Land. After that I will cover some of the specific abstractions and how they are different in Jabz.

Non-prefixed method names

Jabz uses non-prefixed method names. To be a functor an object must have a map method. This is in contrast to Fantasy Land, where a Functor must have a method named fantasy-land/map. Jabz uses non-prefixed method names primarily since they’re more convenient and convenience is one of the primary goals.

One argument for prefixed method names in Fantasy Land is that then libraries can implement the specification even if they currently have methods with the same name that don’t behave according to the specification. In my opinion, disallowing that is a good thing. Having a map method that does one thing and a fantasy-land/map method that does another thing is a source of confusion. It creates situations where map(f,foo) might do something different than foo.map(f).

Requiring non-prefixed methods ensures that if a structure supports Jabz it is not allowed to have, for instance, an improper map method. Jabz demands more from implementations. But it also means that users can rely on implementations having easily accessible methods that behave as expected.

Beyond minimal complete definitions

Each abstraction specified by Fantasy Land is defined as a set of methods. For instance, foldable is defined by a reduce method (I prefer the name foldr so I’ll use that going forward).

Part of the reason why the foldable abstraction is useful is that, building on top of this single method, we can create many more. For instance, we can derive a function for getting the number of elements in any foldable.

function size(foldable) {
 return foldable.foldr((n, m) => n + m, 0);
}

This is an example of a derived method.

A derived method is one that can be defined in terms of other, often more fundamental, methods.

In all cases the number of methods that Fantasy Land requires by its implementations are as few as possible. What it defines constitutes a minimal complete definition of the given abstraction.

A minimal complete definition is a set of methods describing an abstraction where none of the methods can be derived in terms of the other.

However the size function derived above is problematic. It takes O(n) time, where n is the size of the foldable. Most data structures maintains a size that can be obtained in constant time. Thus, for these data structures using the generalized size function incurs a prohibitively expensive overhead. In practice this means that our abstracted size function, sadly, isn’t all too useful. But with the Fantasy Land specification we can’t do better.

An abstraction that is unnecessarily costly with regards to performance is often impractical.

Haskell solves this issue by including a size method as part of the Foldable type class. Jabz takes a similar approach by specifying that foldables must have a size method. This means that implementations of foldable can optionally implement a performant version of size. Alternatively, they can choose to rely on the default, slower one that Jabz provides.

This is a general trend: where Fantasy Land only contains minimal complete definitions in the specification, Jabz on the contrary includes any method that some specific implementations might benefit from implementing in a specialized way.

Supported by code

The fact that Jabz specifies a lot more methods than Fantasy Land places an extra burden on implementations. Therefore these are meant to be created with support from the library. This makes it very convenient to implement the abstractions.

Jabz achieves this by offering functions that take classes and ensures that they have the necessary methods. These functions only require that some minimal complete definition is present. Beyond that, missing methods will automatically be filled in with default derived implementations.

For instance, Jabz requires functors to have both a map and a mapTo method. But since mapTo can be derived from map, an implementation doesn’t have to specify it. A functor can be implemented like this

@functor
class MyFunctor {
 ...
 map(f) {
 ...
 }
}

The functor function ensures that MyFunctor satisfies the functor specification. It automatically installs a default derived mapTo on MyFunctors prototype. Each abstraction in Jabz comes with a matching function for creating implementations. Using them as a decorators, as above, looks nice but is of course not required. Decorators are just fancy syntax for applying functions to classes.

Monoid with nicely named methods

Fantasy Land monoids must have the two methods empty and concat. These names make sense for the list instance of monoid where empty gives the empty list and concat does list concatenation. However, for other instances they are very awkward. One example is the Max monoid whose elements are numbers and where infinity is the identity element and the merge operation returns the minimum of two numbers. In this case empty is a very counterintuitive name for a function that returns infinity.

In Jabz the monoid methods are instead called identity and combine. These names should be fairly easy to understand while ensuring that no specific instances of Monoid ends up with non-intuitive names. The idea is that abstract concepts should have abstract names.

Speedy applicatives

If we have a function that takes one argument, we can apply it to a functor with map. However, we can’t apply a function that takes n arguments to n functors. That is what applicative was made for.

If f is a function from three arguments and a, b and c are applicatives, we can use Fantasy Lands ap like this to apply f to the applicatives:

c.ap(b.ap(a.map(of(f))));

This an awkward way of applying a function to two applicatives. So we’d probably abstract the pattern into a function called lift. It might work like this:

lift(f, a, b, c);

However, there is a problem here. Let’s say f is any function taking n arguments. If we only have the methods ap and of, there is no way to apply f to n applicatives without currying f and calling the curried function n times. This hurts performance pretty badly. In most cases it may not matter. But why have applicatives with an unnecessary performance overhead?

Unplaced with the situation, Jabz allows applicatives to bring their own lift method. lift can be derived, so if they don’t they will be given the default slow one. This has the significant advantage that for a specific structure it is often easy to implement lift so that the function to lift does not have to be curried and is only applied once.

To see what the difference can be in practice I’ve created a small benchmark that compares lifting a function over Jabz’s Maybe with lift and with ap. The source code can be found here.

-------------------- `ap` vs `lift` on `Maybe` --------------------
lift 9150491.49 op/s ± 4.45% (68 samples)
ap 1665864.27 op/s ± 1.31% (85 samples)
---------------------------- Best: lift ----------------------------

Of course this is a small micro-benchmark but it does show that lifting a function with ap is expensive. Since lifting is pretty much what applicatives are good for, this means that Jabz applicatives come with no overhead, whereas Fantasy Land’s come with an inherent slowdown.

Monads with do-notation

When Haskell began using monads, do-notation was introduced along with them. The reason is simple: monads are not very convenient to work with without do-notation. Hence, I believe that in order to make monads practically useful in JavaScript, we need a substitute for do-notation. Fortunately, such a thing is possible by using JavaScript generators. I first saw this brilliant idea in the library Fantasy Do. Jabz implements this and calls it “go-notation”—because do is a reserved word in JavaScript. It might stand for “Generato-dO-notation”. With this technique we can get do-notation like this.

const value = go(function*() {
 const a = yield someFunctionReturningAMonad(1);
 const b = yield iAlsoReturnAMonad(2);
 return doSomethingWithTheBoundValues(a, b);
});

which is comparable to

value = do
 a <- someFunctionReturningAMonad(1)
 b <- iAlsoReturnAMonad(2)
 return doSomethingWithTheBoundValues(a, b)

So the string “= yield” should be read as Haskell’s “<-”.

This form of do-notation is immensely useful. But due to some unfortunate technical limitations of generators, the do function has to behave very differently for monads that invoke the callback to chain several times and those that only invoke it once. Therefore, Fantasy Do exports two different functions for these two cases. This seems like a minor inconvenience, but it breaks the abstraction. A single application of do-notation can no longer work for all monads as it should.

Let’s say we have an interface for monads with a random method. The random method takes two integers and returns, in the monad, a random integer between the two. Then we might write code like this:

function veryRandom(m, n) {
 return do(function*() {
 const a = yield m.random(0, n);
 const b = yield m.random(n, n * n);
 return m.of(a + b);
 });
}

The example is fairly silly, but the point is that veryRandom should work for any monad m that has a random method. One monad that might implement this is IO, which would actually generate a random variable. Another candidate is the non-determinism monad, aka. the list monad which would instead return a list of values in the given range. But since IO only calls its chain parameter once, and List calls it several times, Fantasy Do would require us to use two different types of do-notation.

The end result is that code which should work for all monads ends up only working for some monads. This breaks the abstraction. To fix this, Jabz simply requires all monads to have a multi property. The property declares whether or not the monad invokes the callback to chain multiple times. This small addition to the specification makes completely general do-notation possible, which in turn makes monads a lot more useful.

Foldable

Foldables in Jabz benefits significantly from the inclusion of more methods in the specification. But I’ve talked about that already. So let’s instead look at how Jabz regains some power that was otherwise lost to the fact that JavaScript isn’t lazy.

Consider the aforementioned find.

function find(predicate, foldable) {
 return foldable.foldr((e, a) => predicate(e) ? just(e) : a, nothing());
}

Had we coded this nifty function in Haskell, execution would have stopped as soon as an element in the foldable satisfying the predicate had been found. So is the beauty of laziness. JavaScript, on the other hand, is a bit of a workaholic, so the actual function above would always iterate over the entire foldable. In many cases, that will be a lot of wasted effort.

Jabz remedies the situation by adding shortFoldr and shortFoldl to its foldable specification. They are like the normal folds except that the accumulator function has to return a value wrapped in an Either. right means “keep going” and left means “pull the breaks, I’m done”. Both of these are deriveable, but implementations will have to implement them to get the benefits of short-circuiting.

This makes it feasible to implement quite a bunch of additional derived functions compared to what only a strict right fold gives us. Examples are find, findLast, take and any.

Additionally, this also means that infinite data structures can be used with Jabz’s foldable. In fact, Jabz ships with a simple infinite lazy list.

take(5, map((n) => n * n), naturals); //=> [0, 1, 4, 9, 16]

Here naturals is an infinite list of the natural numbers. First we square them with map and then we take the first five with take. This is possible since take utilizes the shortFoldl method on foldables.

Conclusion

We’ve covered some of the main differences between Jabz and Fantasy Land. I hope I’ve convinced you that Jabz brings some interesting ideas to the table. Especially in terms of creating low-overhead abstractions with as many features as one can squeeze out of the them.

Jabz is still far from finished. As a specification Fantasy Land is more comprehensive. Jabz currently only specifies functor, applicative, monad, foldable and traversable. And while it does provide both a healthy set of utility function for working with the abstractions and some commonly used implementations of the specification there is still a lot to add. Contributions and feedback is much appreciated.

The library can be found on Gitub.