About a week ago, I noticed that Browserflow was feeling quite sluggish. I mean, there's a lot involved in automating a browser, but it just seemed way too slow to be reasonable.
To set a baseline, I wanted to see how fast a script should run in the absence of any automation. To be honest, this isn't much of a helpful comparison because it's not reasonable to expect that an application that's issuing one command at a time to a page will get anywhere close to the performance of running a loop that's optimized by modern Javascript engines.
The test case that I came up with is simply printing to the console. Here's what it looks like running for one second (I'm guessing printing continues for much longer than a second because they've been queued up during the second of execution):
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/69c13899-1990-488f-b321-291b4808c0b8/bare.mov
The final result: 18,000 prints
Again, not really that useful as a baseline, but interesting to know.
In order to measure Browserflow's performance, I recreated the script above using Browserflow's commands, except I made it run for 10 seconds instead of 1:
If this were running directly in the inspector, it would print over 180,000 times in 10 seconds.
So how does Browserflow do?
It prints 27 times over 10 seconds. Hell, I could copy and paste on my keyboard faster than that.
Here's a snippet of it running:
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/425783aa-5c9b-4308-b043-9102d2da0c89/full-save.mov
To be clear, performance isn't the highest priority for task automation. It's much more useful to have a slow automation that runs reliably than a fast one that works 80% of the time. For many tasks, the speed of the automation isn't even important — the benefit comes from not having to do it yourself.