Compute power costs money.  This is one reason why it is important that developers write their regular expressions (regex) with efficiency in mind.  It also needs to be written correct so that it functions explicitly as intended.  I was using a SaaS tool to simulate the performance impacts of certain infrastructure changes this week when I hit a bug because the logic was not correct.  It turned out they were using an unanchored regex and were finding the data in the wrong position.  Since I had a decent corpus of data I thought I’d compare the impact of the proper regex to the improper/lazy one.  (Here “lazy” refers to the developer’s work, not the type of regex.)

Long URL

The tool was supposed to change the domain for certain components in the page so I reroute requests and show the improvement in performance.  Basically I wanted to reroute all of the assets.example.com components through a different CDN.  One URL was incorrectly changed.  The original was similar to:

https://www.socialnetworkname.com/tr/?id=123456789012345&ev=Microdata&dl=https://example.com/&rl=&if=false&ts=1234567890123 &cd[DataLayer]=[]&cd[Meta]={%22title%22:%22LARGEREDACTIONHERE%20more.%22} &cd[OtherTech]={%22og:site_name%22:%22REDACTED%22,%22og:type%22:%22website%22,%22og:url%22: %22https://example.com/%22,%22og:title%22:%22REDACTED.%22, %22og:description %22:%22LARGERREDACTION.%22,%22og:image%22:%22https://assets.example.com/web/images/app-stuf/stuf-1234×1234.1d2d

I’ve added some spaces so that WordPress won’t have this line extend off of the page, but also not turn it into multiple paragraphs.

I was initially puzzled why the tool was trying to reroute the www.socialnetworkname.com through my system.  The URL was long enough in the UI that I couldn’t see that the domain was a parameter deep in the URL.  Once I copied it and pasted it into a text editor I could see the problem.

Regex One Character Short

If this solution was written in Perl, the developer should have used something like:

if ($url =~ /^http(s):\/\/$domain/)

Instead they used:

if ($url =~ /http(s):\/\/$domain/)

Note the missing caret (^).  That one typo is causing a performance hit.  Read on if you don’t believe me.  It also is causing their product to have a bug and deliver inaccurate data.  Far more critical than the performance impact.  Regardless of what language they used, the regex would be the same in concept.  Just coded slightly different.

You see, the first regex example only matches if the data begins with http.  That is what the program really should have been looking for – which URLs do I rewrite the domain for?  It is much faster because if the first character is not an “h” it can move on to the next line to test.  Without the anchor, the regex continues to search the entire line looking for that domain.  Since the domain shows up as a parameter (with the http in front) the SaaS solution decides to change the URL at the beginning of the line.  Instead of checking 1 character, it checks dozens.  It also selects the wrong data to modify.

O’Reilly Conference and REGEX Lessons

Years ago I was fortunate enough to attend the O’Reilly Open Source Convention in Monterey.  I still have the binder from the Regular Expressions course by Mark-Jason Dominus.   Whenever I leveraged REGEX I made an effort to write my logic to be as efficient as possible.

My corpus was 1025 csv files totaling 49k lines.  I leveraged the Perl Benchmark module that ran two different subroutines 1000 times.  The only difference was the regex.  One checked the entire line, the other only checked the start of the line, as I had originally scripted my project.

Run from the terminal, here are the stats:

./getStats.pl 
I found 1025 files.
Benchmark: timing 1000 iterations of Anchored, Fuzzy..
  Anchored: 60.7769 wallclock secs (41.70 usr + 18.96 sys = 60.66 CPU) @ 16.49/s (n=1000)
     Fuzzy: 88.186  wallclock secs (67.87 usr + 20.04 sys = 87.91 CPU) @ 11.38/s (n=1000)

Interesting that the correct regex can run 16.49 times per second while the fuzzy one only can get in 11.38 iterations per second.  And the CPU time 60.66 when done correct and 87.91 when done the incorrect way.  Respectfully it is a 44.9 or 30.9% improvement.  Now for the bug I ran into – they’d see no where near that sort of improvement, but I am certain it would be measurable and worthwhile to fix.

Summary

Minor performance hits might not be noticed by the user.  After all, I can’t switch – it is the unbiased 3rd party resource provided to me by my employer.  But that 3rd party could reduce their costs, perhaps even lower prices and gain more market share if they patched all of the lazy errors like this.  And the impression of their solution’s quality would be better without users seeing this bug.