← All tasks
pythoneliben/pycparser #5Not a task: already works

Necessity of PLY's table files

envgap__eliben__pycparser-5

01 / FAILURE SIGNATURE

As reported upstream

No identifying execution failure has been captured.
Not a benchmark task.
  • The project already builds and runs before the fix, so there is nothing to repair.

02 / ENVIRONMENT RECIPE

Base commit
e6994ed5022974a316900a0d13edc60ca6f7850d
Manifest
setup.py
Reproduce
Awaiting issue-specific recipe
Run under trace
Awaiting a meaningful runtime command

03 / ORIGINAL ISSUE TEXT

eliben/pycparser #5 · read the original issue
In the past I've found it annoying that PLY creates lex/yacc table files from wherever you happen to run the script.  The same is happening with pycparser, so I investigated if these tables actually speed up execution at all with this _particular_ grammar.

I timed the execution of examples\cdecl.py over 50 runs, and found that removing the tables (https://github.com/Syeberman/pycparser/commit/c2187621698c3352cf4a703431061079b0a78de1) actually made execution _faster_: 44.77 seconds over the 50 runs without tables versus 47.44 with (with tables already written out).  (Win7 Intel Core i7-2600 @ 3.4GHz)

It seems David Beazley himself has also questioned the necessity of these tables, as recently as a year ago:
http://comments.gmane.org/gmane.comp.python.ply/636

The only benefit I see for these tables is to allow Python's optimized mode to be used:
http://www.dabeaz.com/ply/ply.html#ply_nn38
I tested with -O (after cleaning __pycache__) and it works just fine, but -OO does indeed fail.  More investigation would be needed if -OO support was necessary (perhaps there's a way to keep docstrings for certain modules).
Continue on GitHub ↗

04 / LABELS

Labels from the report text only; not yet run

No supported category has been assigned.

Label rules and the text that matched
[]