On Fri, Jan 31, 2020 at 3:17 PM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > On 1/02/20 3:17 am, John Skaller2 wrote: > > When I ran Cython on a two line Python function I got this from wc: > > > > 4276 13798 161338 oldtest.c > > That seems a bit excessive. > > > A lot of the emitted code appeared to be run time and compile > > time support code which wasn’t actually used. > > Not sure what's going on there. Pyrex made efforts to only > include support code that was actually used, but Cython > has changed a lot since then and I haven't been following > its development closely. Either it's slipped on that, or > the support code has become more bloated.
Cython attempts to do the same. Taking a quick glance at an auto-generated file for an empty .pyx, we have ~200 lines of macros normalizing various C compiler issues ~500 lines defining macros to normalize across Python 2.7-3.9 ~200 lines of providing defaults for various CYTHON_ macros ~300 lines of macros for optional optimizations for CPython details (vs. using more public/pypy compatible, ... APIs) ~300 lines module setup code. Even for trivial modules, we still declare and call functions for creating globals, preparing types, etc. even if we don't have any globals, types, etc. ~300 lines exception handling and traceback creation ~700 lines conversion for basic int and string types (which we assume to be available in various utilities). Much of this is macro-heavy code, to allow maximum flexibility at C compile time, but much would get elided by the preprocessor for any particular environment. Extra utility code is inserted on an as-needed bases, e.g. function creation, various dataytype optimizations, other type conversions, etc. These are re-used within a module. A two line function could add a lot (e.g. just defining a function and its wrapper is a good chunk of code, and whatever the function does of course). I agree there's some fat that could be trimmed there, but not sure it'd be worth the effort. > Can you remove any of it and still have it compile? If > so, filing a bug report might be useful. +1 > > Is there an option to use an #include for the standard stuff? > > There are upsides and downsides to that as well. The way > things are, the generated file is self-contained, and can > be shipped without worrying about it becoming disconnected > from a compatible version of the include file. This is > important when details of the support code can change > without notice between Cython releases. +1 We have an option "common_utility_include_dir" that would create a shared utility folder into which the compiler could create (versioned) #includable files to possibly be shared across many modules, but it was never completely finished (and in particular was difficult to reconcile with cycache, which is like ccache for Cython, due to the outside references a cython artifact could then produce). We've thought of going even further and providing a shared runtime library, but that has some of the same issues (plus more, though in some cases we use the pattern where every module declares type X, but before creating its own looks to see if one was already loaded to let modules share the same internal type at runtime). _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
