Massive reduction in performance after 1.5.0

Describe the bug After the 1.5.0 release, there appears to have been a significant reduction in performance. For instance, here is the output of time bandit -r . using 1.4.0:

17.56user 2.12system 0:21.22elapsed 92%CPU (0avgtext+0avgdata 90712maxresident)k
182728inputs+0outputs (0major+45973minor)pagefaults 0swaps

And here it is with 1.5.0:

261.46user 3.96system 4:27.26elapsed 99%CPU (0avgtext+0avgdata 89164maxresident)k
362728inputs+0outputs (8major+45690minor)pagefaults 0swaps

To Reproduce Steps to reproduce the behavior:

1. Run time bandit -r . within a medium to large-size project on 1.4.0
2. Note the time.
3. Run the same command again, but with bandit 1.5.0
4. Compare the two times. You should see a significant drop in performance

Expected behavior Performance consistent or comparable with 1.4.0

Bandit version

bandit 1.5.0
  python version = 2.7.15rc1 (default, Apr 15 2018, 21:51:34) [GCC 7.3.0]

[ehooo]

I just check the function fnmatch on python core and it was changed: https://github.com/python/cpython/blob/2.7/Lib/fnmatch.py#L69 https://github.com/python/cpython/blob/3.4/Lib/fnmatch.py#L64

Changed on the commit: https://github.com/python/cpython/commit/5b0c1e07ca169feced6d6458f80c2b9ccc6227e0#diff-b62de5c6bce57a277ae7bc60324011ec

[KelSolaar]

A quick test I did was just changing this line:

From

if name is not None and fnmatch.fnmatch(name, qn):

To

if name is not None and name == qn:

and I went from 14m48.641s to 0m20.871s while removing 1 false positive. Given that it seems like regex matching should be optional and not the default? I will certainly monkey-patch the definition on our end.