Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • sac2c sac2c
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 403
    • Issues 403
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • sac-group
  • sac2csac2c
  • Issues
  • #2279
Closed
Open
Created Jan 05, 2022 by Robert Bernecky@rbeDeveloper

Painfully slow Stdlib build needs fixing

Once upon a time, there was a unit test bug that caused me grief:

. Some time ago, those apex unit tests (#2278) ran clean. They no longer do so. I was going to use our dear friend, git bisect, to see if I can determine when that unit test code ceased to work.

However, the fact that it can take 45 minutes to compile the Stdlib makes use of
this tool utterly impractical, unless you can come up with a failing example that
does not require Stdlib. The work required to develop said failing example can take
days or weeks. This is NOT a good use of our time and energy.

The critical path in a Stdlib build is, based on observation while waiting for things
to complete, long, much like a strand of spaghetti. We could get, I think, a
factor of two speedup by building all targets concurrently (e.g., seq and mt_pth).
I don't have any other bright ideas. Or other kinds.

I think the seq/mt_pth change "should" be simple, but there is presumably something that makes it non-simple.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking