DEV Community: Tom

Use Growth Strategies of Today's Biggest Newsletters to Grow Your Startup

Tom — Wed, 23 Jun 2021 12:56:49 +0000

One question has been growing in my curiosity over the last few weeks: How did the biggest newsletters fuel their growth? Was it the audience niche they chose, the specific topic selection in each newsletter, consistent high quality writing, or just pure luck?

In search of an answer to these questions, I do some digging on the growth strategies behind today's largest newsletters, an uncover what they all have in common.

TLDR

Content Curation, not Content Creation

Many of the largest newsletters are not creating original content, instead they are curating content and distilling the most important information for their audience.

Product over Revenue

During each stage of growth, the founders of each newsletter made decisions to improve the quality of their newsletters, even if it meant less revenue in the short term.

Milestone Based Referral Programs

Every newsletter had a referral program, which they all continue to maintain, and many of the founders say outright that the referral programs were the key to their growth.
Referral programs were structured so that the first milestone was easy to achieve, and providing the first milestone prize cost the newsletters nothing. This was usually membership to a closed Facebook group.
Prizes for higher milestones were structured so that as the value of the prize increased, the acquisition cost of every additional subscriber actually decreased.

Delivery Time

Each newsletter arrives at 6am, not only a time when subscribers are mentally fresh and ready for news, but also a time that helps to ensure a higher open rate.

The Morning Brew ($13,000,000 ARR)

Founded in 2015, The Morning Brew is a daily newsletter that provides business-minded millennials with the latest news surrounding the business world. It currently employs 33 people, 13 of which are solely dedicated to sales, has 1.8 million subscribers, and sports an impressive 42% open rate - a clear signal of high quality content.

Newsletters are published 6 days a week, and are sent at 6am to ensure that each email is the first to arrive in their subscribers inbox each morning.

The Morning Brew employs a milestone based referral program, which the founders point to as the secret to their successful newsletter growth.

Building the product to its highest quality sometimes seems like you may not be doing best for your newsletter or Saas, but it always the best move in the end. The Morning Brew implemented double opt in for subscriber sign up in the referral process, and even though they thought this would hurt their referrals, they actually saw an 85% conversion rate on referral signups going on to confirm their emails (not as big of a hit as you may have guessed).

The Morning Brew's Refferal Program Milestones:

In The Morning Brew's milestone referral program, notice that the first milestone is actually incredibly easy to achieve for any new subscriber, and the payment for a subscriber successfully reaching the first milestone costs The Morning Brew absolutely nothing.

The low barrier to obtaining the first milestone reward gives subscribers the first nudge they need to start sharing, almost all subscribers are guaranteed to get 3 referrals with a simple share to Twitter or Facebook, and once a subscriber starts sharing, they are more likely to continue sharing to reach further milestones.

One very interesting feature of The Morning Brew's milestone referral program is that even though the rewards get better for the user, the Cost Per Acquisition of a new subscriber actually decreases for The Morning Brew as the referral rewards get more expensive. So referring subscribers get better swag for higher numbers of referrals, but The Morning Brew pays less for each new subscriber.

According to the founders:

"When someone refers 15 people, the CPA on those referred is $0.23 ((cost of phone wallet + stickers) / 15). We’ve actually managed to spend less per subscriber as someone continues to refer additional people."

The Skimm ($30,000,000 ARR)

Founded in 2012, The Skimm is a daily newsletter focused on breaking news and emerging current affairs within the last 24 hours. It currently has 7 million subscribers, 39 employees, and it caters primarily to an audience of millenial women.

Just like The Morning Brew, The Skimm is sent at 6am so that it arrives first in each subscriber's inbox.

One interesting feature of the early growth strategy used by The Skimm, is that they didn't exactly play fair to get started, and they don't try to hide it. They origainally pulled email addresses from chain mail and from their friends on Facebook to get an inital mailing list of 5500 contacts.

They also relied on heavy self-promotion, I mean this in a good way, and marketing in the beginning, which is something that all newsletter creators should master.

"They emailed every news anchor, media liaison, and press agent they could think of, name-dropping their experience as associate producers at NBC to entice people to check it out."

Their early marketing strategies worked and they reached 100,000 subscribers in their 1st year of publication.

Their product first focus led them to reject 100% of the offers that they had received to work with advertisers, fearing that they would lose some editorial control and risk potential damage to their newsletter and reader experience. They lead with a quality first focus, and the rest of the pieces later fell into place.

The founders said of the choice to reject advertising in the beginning:

"Reader feedback is vital to helping us understand why people read theSkimm and why they ultimately share it with others. And thankfully we get a LOT of daily feedback. It helps us understand a) what we are doing well, b) what we could be doing better, and c) what are things we could be doing, but may not have been thinking about."

Just like The Morning Brew, a major growth driver for The Skimm was a milestone based referral program named the ambassador program. The Skimm's ambassador program used a tiered reward system similar to The Morning Brew's referral program.

The Skimm puts soo much emphasis on their referral program that they put together a referral program cheat sheet.

- 10 referrals (Skimm Tote)
- 25 referrals (T-shirt)
- 50 referrals (Skimm Newsletter Shout Out)
- 100 referrals (Umbrella)
- 150 referrals (Phone Case)
- 200 referrals (Wine Sippy Cup)

When 10 referrals for a Skimm subscriber signed up, the referring Skimm subscriber gained access to private Facebook and Linkedin groups - just like The Morning Brew, the first rewards for The Skimm referral program were free and easy to achieve.

This referral program helped The Skimm to grow to 50 employees with 6 million subscribers by 2017, and a 7 million subscribers today.

The Hustle ($1.5 - $2.5 million MRR)

Founded in 2014 as a conference for entrepreneurs, The Hustle morphed into a newsletter in 2015. Starting with a 300 subscriber mailing list, it quickly grew into a newsletter of over 100,000 subscribers by 2016, and 1.5 million subscribers in 2020. It reached 7 figures in revenue by 2017, and according to the founder Sam Parr, is on track to reach $100 million in revenue by 2025.

The Hustle targets millennials with stories focused on tech and culture written with an informal tone and conversational style. It is reported to have an open rate in the range of 35%-40%.

Like The Morning Brew, and The Skimm, The Hustle uses a milestone based ambassador referral program, with prizes including hoodies, hats, and tickets to Hustle Con.

Oh, and it's first tier is easy for subscribers to achieve, and costs The Hustle nothing to provide (I think there is definitely a pattern developing here).

The Water Coolest ($4,000,000 ARR)

The Water Coolest newsletter was started in 2017, has a mailing list size of 50k subscribers, and currently supports 22 employees. Like The Morning Brew, The Skimm, and The Hustle, the Water Coolest runs a referral program (proudly displayed at the top of their webpage), but unlike the other newsletters, the founder of The Water Coolest took a slightly different approach to growing the newsletter in the early days.

Early on, the newsletter used influencer marketing via meme finance accounts on Instagram. These accounts allowed The Water Coolest to reach subscribers cheaper than more traditional advertising alternatives.

The Water Coolest also sends their email out at 6am daily, and their first referral milestone is very easy to achieve.

I hope this helps all creators who are working to get their newsletter off the ground, and even established newsletters looking for ways to improve their growth.

Feedback on the UX for my startup's viral marketing strategy?

Tom — Wed, 05 May 2021 13:03:46 +0000

Hi All!

Over the past few months I have been building a newsletter platform, https://postheat.com, and I just released a new feature that is itself a marketing strategy.

Let me tell you about the feature…

I read an article a while back about using the power of other networks to market your startup (i.e. leveraging Twitter, Facebook, and LinkedIn connections). In the article, the author used Twitter to create a viral marketing strategy by letting users create tweets with a link back to the authors startup as part of the product.

I have decided to apply this idea to postheat.com.

The key idea is to align my users incentives (growing and promoting their newsletters), with my incentives (growing and promoting my startup).

So, I’m adding a new feature to postheat.com that will allow my users to do just that – quickly promote and grow their newsletters on Twitter, while simultaneously helping me to grow and promote my startup.

This is how I am planning it out:

• I have added an “Insert Tweet” button that lets users import tweets from their twitter feeds directly into their newsletters while they are writing

• When a user finds a tweet they want to import, they will have the option to automatically create a re-tweet, notifying the original tweet author (and everybody else who sees the re-tweet) that they are adding that tweet into their newsletter hosted on postheat.com, with a link to their subscriber sign up page.

Ex. A user finds a Product Hunt tweet to add to their newsletter, so they click the mail icon.

The Tweet is added to their newsletter...

A tweet is then created with a notification to Product Hunt indicating where they can subscribe to the newsletter that is writing about their tweet. Here I’m using the PostHeat twitter account, but Tweets will be sent from each users respective Twitter account.

A percentage of Twitter users who see the tweet will sign up for the newsletter, and another percentage will start their own newsletters on PostHeat.com, repeating the marketing cycle.

I’m hoping that this will help to serve my users by providing them an easy way to promote their newsletters, as well as, an organic / viral marketing strategy for my startup. However, right now the retweet checkbox is checked by default when users choose to import a tweet into their newsletter, and I’m not sure if this is crossing the line with my users. Although I do provide an explanation of what happens if the box is checked, I am trying to decide if this should be more of an opt-in feature.

How would you feel if you ran into this as a user? I’d appreciate any thoughts, as I really do believe this feature will benefit both my users and my startup.

An update to my no-code html email builder

Tom — Tue, 27 Apr 2021 12:23:36 +0000

A few weeks ago I shared a post about a no-code tool I built for creating html emails (https://dev.to/tb/stop-coding-your-own-html-emails-i-created-a-no-code-email-template-builder-3f2h)
I received an amazing response from the dev.to community, with 243 users checking out the tool, and 26 devs signing up over a 3 day period.

This response, along with some of the feedback I received, made me realize that creating html emails is still a time intensive process, and a major pain in the butt for devs.
So, to further help devs create html emails in a no-code manner, I spent my spare time in the last couple of weeks adding to the no-code html email builder with a feature for devs to create their own custom email template layouts.
As before, this tool is still free and openly available to anybody and everybody.
If you want to create your own html template layouts for emails:
(1) Log in to https://postheat.com (signup is free)
(2) Go to the template builder page at https://postheat.com/buildTemplate
(3) Drag and drop elements to build your template (and save it!)
(4) Use the template in your email design on https://postheat.com/create (You can export the html here as well)

Any feedback is greatly appreciated!

Stop coding your own html emails. I created a no-code email template builder.

Tom — Wed, 03 Mar 2021 14:03:37 +0000

Hi Devs!

I wanted to share a no code email template builder I'm creating as part of my larger project PostHeat, a platform for building (and sending) email.

I started this project because I always had a really tough time building emails for my past side projects. I kept running into style issues on different devices, and I could not find an existing tool where I could both build an email template, and write the email in the same screen with a clean and easy UI.

So I decided to build such a tool for myself...

I realized that this is a larger problem for devs in general, and that it has several sub-problems:

Not all devs are good designers (I fall into this category), so designing an email layout can be difficult
Many devs would rather spend time coding than designing an email
Tweaking css to get html emails to look good is a pain in the butt
Existing solutions don't solve these problems in an easy way, many of them are a pain to use due to bad UI/UX

I'm hoping that I can solve all of these issues with a single What You See Is What You Get (WYSIWYG) email template builder and editor that devs can use to build great looking emails fast.

The most relevant feature to devs is a direct HTML export button, so that after an html email is created, the html can be copied with single click.

I hope this will make many devs lives easier, and help them to build html emails faster and with less headache!

I'll stop talking here, you can probably best see what I'm talking about by trying it out for yourself:

Go to postheat.com/create to access the editor
Build a great looking email, then click on the </> button to get the html for the email you just built.

Copy the email html and paste it into your own projects!

I hope you find this useful! Any feedback on how I can improve the html email builder is greatly appreciated!

Thank You!
TB

An Index of Personal Websites

Tom — Tue, 24 Dec 2019 00:37:55 +0000

In a recent Hacker News thread developers shared their favourite personal websites (https://news.ycombinator.com/item?id=21737529). Not only was the design of each domain amazing, but the content on many of the websites was deeply captivating as well. All of these websites were awesome because they all contained content and articles written by experts in their respective domains.

I found this list inspiring and decided to create a more official index of personal websites, where anybody can add a personal domain with a description so that their thoughts and ideas can be openly shared with others.

If you are interested you can check out the list or add to it at https://lastinlastout.com.

I'm hoping over time this will grow to a really cool list of websites where people can find other content that interests them.

The current design is a very rough mvp that contains two tables and a submission form.

The top table has the host domain of the most recent newly submitted websites
The bottom table has the full url of new endpoints that were most recently submitted (used for new blog posts, etc...)

The index contains a few features to try to make the UX interesting:

No url can be submitted twice -- any url submitted a second time is ignored
New endpoints for a given domain can be submitted, but will only show in the updates table, and will never impact the top table if any endpoint on the domain was previously submitted. I hope this will not only a give visitors an opportunity to discover new domains, but also give an opportunity for repeat submitters who may want to submit new blog posts or website updates.

I think the best part about this website is that it is not greedy for traffic. i.e. It does not try to keep users, but instead points them outward to creators own websites. I hope this feature will keep the domain owners coming back to submit new updates as they create more content on their own websites.

I hope you enjoy!

Homemade Time Series with OCaml

Tom — Mon, 09 Dec 2019 00:39:23 +0000

Sometimes I just build things out of curiosity so that I know how they will work instead of using something pre-made. So in the spirit of GROKing something via building it, I recently created my own time series module, and thought I would share it with others. I hope you enjoy my thoughs and creation of a simple time series module using OCaml.

I'm testing out two different methods of building a time series module. First, I am building a time series module centered around a record type that holds the time series data along with meta-data. Next, I'm going to do the same thing with modules and functors. Having both versions will let me make a comparison on the pros and cons of each implementation.

What I want in a Time Series module

1 - Simplicity (in the implemenation and interface)
I want a very simple interface that anybody can undersand with only a passing glance (no documentation or instruction manual needed). All behavior must be completely obvious and as anticipated. The functionality should be distilled to only what is necessary, but easy to extend. I think an implementation using record types will probably be the simplest because there will less moving parts involved.

2 - Speedy (Enough)
This thing cannot take forever for obvious reasons, but I'm not too concerned with speed. I don't use any seriously large data sets, and if something really fast is needed in the future, I can make it as an extra add on. What I'm most concerned about with speed is being able to quickly tinker with the module in the top level when I'm experimenting with data. So speed really counts when measuring how quickly other people can learn to use the module, and how quickly the module can be used.

3 - Lightweight
I don't want 100 requisite libraries for my time series library to compile. I think this would be annoying and rude to other developers who may use it in the future (including the future me). I really just want this to feel like a plug and play module, where you can load it in the toplevel and it just works right out of the gate with all code being self-contained.

4 - Flexible
I want to be able to track any kind of data. A few that spring to mind are binary, categorical, ordinal, integers, and floats, but this needs to work for everything right off the bat. Although modules in OCaml are generally more flexible, I don't think their flexibility and extendability will provide much value here.

Other Thoughts before building
I want to be able to track my data over a fixed set of arbitrary time periods. I'll keep it simple and assume that I will only be using time intervals of days, hours, minutes, or seconds. I also don't want to force the use of any granular timestamp data when it is not needed. Ex. My time series should not have to care about the time of day a data point was observed if my series is a daily time series.

With the pre-requisites in mind I'm organizing the code into four files:

Utils.ml - contains the basic building blocks of my module including all common types and functions

TimeSeriesWithRecords.ml - the implementation of a time series module using a record type to store all information

TimeSeriesWithModules.ml - the implementation of a time series module using functors to generate modules that store all information

Test.ml - a quick test of both methods with a benchmark comparison

To define the core components, I really only care about capturing a value and a time as a data point. Then storing a sequence of these data points.

First I want to define a clear way to track dates - clearer than what is provided by the Unix module. I though about counting months from 1 to 12, instead of using the default Unix method of counting from 0 to 11, but I think this can get confusing (what if I forget or dont notice). To make things easier, I think it is better to use a type for month that cannot be accidentally misinterpreted, so I will add the following month type, and create a date type that cannot be misintrepreted. I'm also setting up an interval type to note the smallest unit of intended measure in the series. This can be useful if I want a daily series, but I don't always have observations on consecutive days.

type month =
  | Jan
  | Feb
  | Mar
  | Apr
  | May
  | Jun
  | Jul
  | Aug
  | Sep
  | Oct
  | Nov
  | Dec

type interval =
  Seconds of int
  Minutes of int
  Hours of int
  Days of int

type date = {
  year : int;
  month : month;
  day : int;
}

type time = {
  hour : int;
  min : int;
  sec : int;
}

I'm also setting up a data_point type that will wrap all information together that is relevant to a single observation.

type 'a data_point = {
    date : date;
    time : time option;
    value : 'a option
}

These are all stored in the Utils.ml file along with some other functions that are useful, but probably boring to read so I'll leave them at the bottom of the post for anybody interested.

The Record Implementation

Now it is very straightforward to create an ordered collecton of data points. The type 'a time_series not only contains the data, but useful metadata as well.

type 'a time_series = {
  data : 'a data_point array;
  sorted : bool;
  missing_points : bool;
  interval : interval
}

Now data can actually put into a series!

There is still a huge problem, which is that I will be dangerously building the time series myself. I need a helper function to do this that will not make mistakes. But, before I can build a function to create a time series safely, I will need some helper functions to do a few important things:

(1) Check if the series is sorted

I'm going to cheat some here and just assume that if I am going to build a new series, then I am always going to sort the data and set sorted to true. Maybe this means that the sorted record field is unncessary? I don't think so, it clearly tells me that the data is sorted (as long as the safe time series builder functions are used)!

let sort_series data =
  Array.fast_sort (fun x y -> date_compare x y) data

(2) Check if the series is missing any data points between the earliest and latest data points

let mkdate (d : date) = {
  Unix.tm_sec = 0;
  tm_min = 0;
  tm_hour = 0;
  tm_mday = d.day;
  tm_mon = int_of_month d.month;
  tm_year = d.year;
  tm_wday = 0;
  tm_yday = 0;
  tm_isdst = true
}
|> Unix.mktime

let make_next_date interval current_date =
  let open Unix in
  let next_dt =
    localtime (
      (fst @@ mkdate current_date) +.
      float_of_int (seconds_of_interval interval)
    )
  in
  {
    year = next_dt.tm_year;
    month = month_of_int next_dt.tm_mon;
    day = next_dt.tm_mday
  }

(* NOTE: This function assumes that data is always sorted *)
let is_missing_points time_series =
  (* TODO: Raise an exception here if the data is not already sorted! *)
  let rec run prior_date remaining_points =
    match Array.length remaining_points with
    | 0 -> false
    | _ ->
        let next_date = (Array.get remaining_points 0).date in
        if next_date <> make_next_date time_series.interval prior_date
        then true
        else run next_date (Array.sub remaining_points 1 (Array.length remaining_points - 1))
  in
  run
    (Array.get time_series.data 0).date
    (Array.sub time_series.data 1 (Array.length time_series.data - 1))

Finally, all of the necessary functions exist to build a time series safely.

let build_time_series data interval =
  let data_copy = Array.copy data in
  sort_series data_copy;
  let missing_points =
    is_missing_points {
      data = data;
      sorted = true;
      missing_points = true;
      interval = interval
    }
  in
  {
    data = data_copy;
    sorted = true;
    missing_points = missing_points;
    interval = interval
  }

The Functor / Module Implementation

I want to do the same thing, but with a focus on modules. To get started I can define a module version of the record type type above that will be used to store the time series information.

module type TimeSeries =
  sig
    type t
    val data : t data_point array
    val sorted : bool
    val missing_points : bool
    val interval : interval
  end

I can also setup a functor to build a TimeSeries module. The functor only needs knowledge of the data and the interval for all other calculations. This can be translated into an input module type and corresponding functor to build a TimeSeries module.

module type TsData =
  sig
    type t
    val data : t data_point array
    val interval : interval
  end

module Builder (D : TsData) : TimeSeries =
  struct
    type t = D.t
    let data =
      let data_copy = Array.copy D.data in
      sort_series data_copy;
      data_copy
    let sorted = true
    let missing_points =
      is_missing_points {
        data = data;
        sorted = true;
        missing_points = true;
        interval = D.interval
      }
    let interval = D.interval
  end

Which is better

I'm just doing the minimal testing necessary to see which one I like better. Below there is some common data to test both implementations. I have left some missing values in test_data so that the tests can make sure that both implementations return the series with missing_data = true.

#use "Utils.ml";;
#use "TimeSeriesWithRecords.ml";;
#use "TimeSeriesWithModules.ml";;

let test_data =
  [|
    {date = {year = 2019; month = Jan; day = 1}; time = None; value = Some 1.0};
    {date = {year = 2019; month = Jan; day = 2}; time = None; value = Some 2.0};
    {date = {year = 2019; month = Jan; day = 4}; time = None; value = None};
    {date = {year = 2019; month = Jan; day = 6}; time = None; value = Some 3.0};
    {date = {year = 2019; month = Jan; day = 8}; time = None; value = Some 3.0}
  |]

The record test is very simple, only a single line. Looks like everything is working.

# let ts = build_time_series test_data (Days 1);;
val ts : float time_series =
  {data =
    [|{date = {year = 2019; month = Jan; day = 1}; time = None; value = Some 1.};
      {date = {year = 2019; month = Jan; day = 2}; time = None; value = Some 2.};
      {date = {year = 2019; month = Jan; day = 4}; time = None; value = None};
      {date = {year = 2019; month = Jan; day = 6}; time = None; value = Some 3.};
      {date = {year = 2019; month = Jan; day = 8}; time = None; value = Some 3.}|];
   sorted = true; missing_points = true; interval = Days 1}

The module implementation requires more effort than the record implementation. The data input module needs to be setup, then passed into a functor to build a TimeSeries module with data.

# module TestTsData =
  struct
    type t = float
    let data = test_data
    let interval = Days 1
  end
;;

module TestTsData :
  sig type t = float val data : t data_point array val interval : interval end

# module Test = Builder (TestTsData);;
module Test :
  sig
    type t = Builder(TestTsData).t
    val data : t data_point array
    val sorted : bool
    val missing_points : bool
    val interval : interval
  end

# Test.data;;
- : Test.t data_point array =
[|{date = {year = 2019; month = Jan; day = 1}; time = None;
   value = Some <abstr>};
  {date = {year = 2019; month = Jan; day = 2}; time = None;
   value = Some <abstr>};
  {date = {year = 2019; month = Jan; day = 4}; time = None; value = None};
  {date = {year = 2019; month = Jan; day = 6}; time = None;
   value = Some <abstr>};
  {date = {year = 2019; month = Jan; day = 8}; time = None;
   value = Some <abstr>}|]

This looks great, but the type of value in each data point is abstract. So the setup has to go one step further to make sure that the functor provides a module with a concrete value type. Note that this has to be done separately for each differnt type that is used, which can be non-significant overhead compared to the record implementation.

So it is necessary to setup up a functor for building a float time series, that does the exact same thing as above, but exposes the type of value.

 # module FloatBuilder (D : TsData with type t = float) : (TimeSeries with type t = float) =
  struct
    type t = D.t
    let data =
      let data_copy = Array.copy D.data in
      sort_series data_copy;
      data_copy
    let sorted = true
    let missing_points =
      is_missing_points {
        data = data;
        sorted = true;
        missing_points = true;
        interval = D.interval
      }
    let interval = D.interval
  end
;;
module FloatBuilder :
  functor
    (D : sig
           type t = float
           val data : t data_point array
           val interval : interval
         end) ->
    sig
      type t = float
      val data : t data_point array
      val sorted : bool
      val missing_points : bool
      val interval : interval
    end

Now the output module has concrete data that can be viewed and used!

# module FloatTest = FloatBuilder (TestTsData);;
module FloatTest :
  sig
    type t = float
    val data : t data_point array
    val sorted : bool
    val missing_points : bool
    val interval : interval
  end

# FloatTest.data;;
- : float data_point array =
[|{date = {year = 2019; month = Jan; day = 1}; time = None; value = Some 1.};
  {date = {year = 2019; month = Jan; day = 2}; time = None; value = Some 2.};
  {date = {year = 2019; month = Jan; day = 4}; time = None; value = None};
  {date = {year = 2019; month = Jan; day = 6}; time = None; value = Some 3.};
  {date = {year = 2019; month = Jan; day = 8}; time = None; value = Some 3.}|]

A quick benchmark also shows that with my small test series (of whopping size n=5), there is not a significant difference between the runtime of the two implementations. This (pitiful) test does not feel real at all, so this is something that I'll need to re-visit in the future.

let rec call_n_times ?(count = 0) n f =
  if count < n
  then (f (); call_n_times ~count:(count + 1) n f)
  else ()

let timer n f =
  let start_time = Unix.gettimeofday () in
  call_n_times n f;
  let end_time = Unix.gettimeofday () in
  end_time -. start_time

let build_ts_with_record () =
  let ts = build_time_series test_data (Days 1) in
  if ts.sorted
  then ()
  else ()

let build_ts_with_module () =
  let ts = (module FloatBuilder (TestTsData) : TimeSeries) in
  let module TS = (val ts : TimeSeries) in
  if TS.sorted
  then ()
  else ()

let benchmark n = timer n build_ts_with_record /. timer n build_ts_with_module

# benchmark 10_000;;
- : float = 0.92154114381409

Concluding Thoughts

Althought the functor / module implementation is cool, it feels too complicated for the feature set, but this may change in the future as the module grows. The record implementation seems much more preferable as it is more simple in its implementation and especially in its usage. There does not seem to be any difference in effectiveness between the two implementations, so I have to declare the record implementation as the winner.

I still have a few TODOs left to complete in the module. These seem important, but I don't currently need them and they are probably not interesting to read about.

At the top of the TODO list:

(1) Build an actual test with a larger and more complicated data set
(2) Add functionality to fill missing data, using interval to measure where data is missing
(3) Add functionality to drop values from the time series (ex. where value = None)

All files are available here:

https://gist.github.com/ThomasBrittain/c930febaa60e3cd286420b71cd94bb76

Efficient OCaml

Tom — Sun, 10 Nov 2019 22:59:36 +0000

I am often asked if functional programming is inefficient. The truth is that like all programming paradigms, functional programming can be inefficient, but with a few rules of thumb you can keep your code performant, clean, readable, and functional. Here are a few simple examples of making functional code more efficient.

Before diving in, let's first setup some data to work with. We will work with people, and measure each person in age, height, and weight.

type height = {
  feet : int;
  inches : int
}

type person = {
  age : int;
  height : height;
  weight : int
}

Let's generate some test data to use.

let generate_person () = {
  age = Random.int 99;
  height = {
    feet = Random.int 7;
    inches = Random.int 12
  };
  weight = Random.int 250
}

let rec generate_people n acc =
  if List.length acc < n
  then generate_people n (generate_person () :: acc)
  else acc

let people = generate_people 10_000 []

Also, let's setup a simple function to benchmark efficiency gains for each rule.

let rec call_n_times ?(count = 0) n f =
  if count < n
  then (f (); call_n_times ~count:(count + 1) n f)
  else ()

let timer n f =
  let start_time = Unix.time () in
  call_n_times n f;
  let end_time = Unix.time () in
  end_time -. start_time

Rule 1 - Don't mix filters and maps together in separate steps, combine them when possible.

This will help with general performance of your code, and also looks much cleaner. In the first function dont_1, we first find all people who are 18 or older, and then calculate their height. We are iterating over the list twice, which is clearly not good.

In the second function do_1, we combine the filter and map into a single step. We then only append to the list acc if the person is 18 or older.

let dont_1 () =
  people
  |> List.filter (fun p -> p.age >= 18)
  |> List.map (fun p -> p.height.feet * 12 + p.height.inches)

let do_1 () =
  List.fold_left (fun acc p ->
    if p.age >= 18
    then p.height.feet * 12 + p.height.inches :: acc
    else acc
  ) [] people

let benchmark_1 () = timer 10_000 do_1 /. timer 10_000 dont_1

The performance gains between the two functions are large - the fold version only takes 49% of the time that the filter + map version takes, which is exactly what we would expect if we iterate over one list instead of two.

# benchmark_1 ();;
- : float = 0.492262787773328825

Rule 1.1 - Combine multiple maps into a single function for speed & cleanliness

This is really just a subset of rule 1, but will make your code much cleaner to read, and also more performant.

Rule 2 - Use modules to cache data and avoid re-running the same calculation

Assume that you want to calculate the average height of your population. A quick but naieve way to achieve this is to build a function that will be called each time you want to compute the average. This works, but is drastically less efficient than using a module to cache your population data and average height, then only re-computing the average height when necessary.

Here is a quick way to implement the average height calculation. You can calculate the average by calling dont_2.

let sum =
  List.fold_left (fun acc x -> x + acc) 0

let average (l : int list) =
  (float_of_int @@ sum l) /. (float_of_int @@ List.length l)

let dont_2 () =
  people
  |> List.map (fun p -> p.height.feet * 12 + p.height.inches)
  |> average

A much more efficient way to calculate the population average is to create a module that will hold a list of people with their average height, and only calculate the average height of the list of people if the list of people changes.

module Height : sig
  val avg : float
  val set_data : person list -> unit
end = struct
  let data = ref []
  let recompute_average = ref true
  let cached_avg = ref 0.0
  let set_data new_data =
    data := new_data;
    recompute_average := true
  let avg =
    if !recompute_average
    then (
      cached_avg :=
        people
        |> List.map (fun p -> p.height.feet * 12 + p.height.inches)
        |> average;
      recompute_average := false;
      !cached_avg
    )
    else !cached_avg
end

let () = Height.set_data people

let do_2 () = Height.avg

let benchmark_2 () = timer 100 do_2 /. timer 100 dont_2

The difference here is so extreme if you don't update the data that it's not even worth running the benchmark, but here it is anyway.

# benchmark_2 ();;
- : float = 3.17598111349897812e-05

Rule 3 - Use an accumulator

Building a Fibonacci Sequence is a classic interview question, I used to use it often in two stages.

First, as a softball warmup to set the tone of the interview and allow the candidate to ease into the interview and get comfortable before diving into more challenging topics, "Can you build a function to calculate the nth Fibonacci number?".

This is pretty easy, and should look something like this

let rec fib1 n =
  if n = 1 || n = 2
  then 1
  else fib1 (n-1) + fib1 (n-2)

This function works fine for small values of n, but really starts to slow down for n >= 40. So as a follow up, I would pose the question.

"Can you build this same function so that it is not susceptible to a stack overflow?"

let rec fib2 n =
  let rec run ~acc i =
    if i = n
    then fst acc + snd acc
    else run ~acc:(snd acc, fst acc + snd acc) (i + 1)
  in
  if n = 1 || n = 2
  then 1
  else run ~acc:(1, 1) 3

The function fib2 works much better, and you can clearly see a performance difference if you compare the two implementations for n = 40.

# timer 1 (fun () -> fib1 40);;
- : float = 3.35294890403747559

# timer 1 (fun () -> fib2 40);;
- : float = 6.198883056640625e-06

Rule 4 - Don't abuse lists

The function we created above generate_people is a perfect example of this rule. If we are going to generate a sequence of people, we can use an array instead of a list and get a significant performance boost.

Building a function to generate an array of people is extremely simple:

let generate_people_array n =
  Array.init n (fun i -> generate_person ())

As you can see, the performance gain here is tremendous.

# benchmark_generate_people ();;
- : float = 46.0630876811840153

I hope that you find these quick examples useful. I think that these are some of the most common opportunities for performance gains that you will come across in functional programming on a daily basis.