Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • pypy pypy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 697
    • Issues 697
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • PyPyPyPy
  • pypypypy
  • Merge requests
  • !411

Large c files

  • Review changes

  • Download
  • Patches
  • Plain diff
Closed Bitbucket Importer requested to merge bitbucket/declined-pr-411 into branch/default Mar 07, 2016
  • Overview 1
  • Commits 0
  • Pipelines 0
  • Changes -

Created originally on Bitbucket by mattip

Changesets for this Pull Request have not been imported, because it had been already declined on Bitbucket. Marked as closed by the import user.

create larger c files, fixes make on win32 and should speed up compile on other platforms.

A bit of background: currently we create over 1000 c files, some of which are very small. With this change, we now create ~450. The mechanism to split files ensures none of the files is too large

This is one way to fix translation on windows (we get a MemoryError trying to link so many files together when using a pypy after ver2.6.1). Another would be to use a separate build step in the buildbot, and run translation with --sources, or to use the same prefork trick used on non-windows to create a subprocess early on with a smaller memory footprint (does that work on windows?). The ultimate solution would be to shrink PyPy's memory usage during translation :)

The downside to this approach is that the file name has now gotten lost, i.e. when using gdb the c file name would be something like pypy/module/cpyext.c and the function name something like g_pypy_PyLong_FromLong - so the intobject.py filename has been lost. If we add the filename to the function name, would the debug info size explode?

Comments?

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: bitbucket/declined-pr-411