Optimize regex compilation in Distribution._read_sections

[tirkarthi]

In below lines the regex pattern is compiled for each line in a loop which is not needed since we can just use re.compile once and use the pattern object. This improves the speed as per below benchmarks.

importlib_metadata/importlib_metadata/__init__.py

Lines 528 to 535 in 5c9198c

	def _read_sections(lines):
	section = None
	for line in filter(None, lines):
	section_match = re.match(r'\[(.*)\]$', line)
	if section_match:
	section = section_match.group(1)
	continue
	yield locals()

Benchmark of comparing requires.txt for dask

$  wc requires.txt
 38  31 427 requires.txt
$ python -m pyperf timeit -s 'from importlib_metadata import Distribution; requires = open("requires.txt").read()' 'Distribution._deps_from_requires_text(requires)' -o no_pattern.json
$ python -m pyperf timeit -s 'from importlib_metadata import Distribution; requires = open("requires.txt").read()' 'Distribution._deps_from_requires_text(requires)' -o pattern.json
$ python -m pyperf compare_to no_pattern.json pattern.json --table
+-----------+------------+-----------------------+
| Benchmark | no_pattern | pattern               |
+===========+============+=======================+
| timeit    | 53.4 us    | 30.4 us: 1.76x faster |
+-----------+------------+-----------------------+

[jaraco]

the regex pattern is compiled for each line

That's surprising to me. I thought regex cached these patterns.

Benchmark of comparing requires.txt for dask

Oh, today I learned of pyperf. Thanks for the reference. I'd really like to get this functionality implemented as a 'compare against main' feature. Thanks for sharing.

[jaraco]

I note that as of 3.9, this module has two implementations of a config parser, one in the Sectioned class, and the other in the _read_sections method. Probably those should be consolidated.

[tirkarthi]

I looked into implementation n I can see the caching at https://github.com/python/cpython/blob/af50c84643ce21cfbdfdabbdfae6bd5e1368c542/Lib/re.py#L285 . It has max entries of 512. I am not sure if this is due to the way the benchmark is done in pyperf or timeit. I don't guess the cache limit is reached so still little confused by benchmark result as well.

[jaraco]

After merging #294, I set out to create a test that would capture the performance concern implied above.

As I read into the code further, I observe that this code is only reachable through legacy eggs, which are generally discouraged. Given that the code is discouraged, the performance degradation is unexpected, pyperf is known to be unreliable, and that this code is likely to be unified with the Sectioned class anyway, I'd respectfully like close this issue as won't fix.

If there's a real-world use-case that's impacted by this performance concern, I'll happily revisit it, but my instinct is it's not worth the trouble.