Skip to content

Conversation

@ben-schwen
Copy link
Member

Closes #6908

It dedoubles the code, but due to the recursive call of copyAsPlain, I'm not sure its really cleaner.

Maybe we should add a comment in both functions, linking to each other to not forget updating the code of one, if we update code of the other, and close the issue?

@codecov
Copy link

codecov bot commented Jan 17, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.00%. Comparing base (0216983) to head (ea3a3fd).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #7602      +/-   ##
==========================================
- Coverage   99.00%   99.00%   -0.01%     
==========================================
  Files          87       87              
  Lines       16893    16884       -9     
==========================================
- Hits        16725    16716       -9     
  Misses        168      168              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions
Copy link

github-actions bot commented Jan 17, 2026

  • HEAD=unify_growVector_copyAsPlain slower P<0.001 for DT[by,verbose=TRUE] improved in #6296
    Comparison Plot

Generated via commit ea3a3fd

Download link for the artifact containing the test results: ↓ atime-results.zip

Task Duration
R setup and installing dependencies 3 minutes and 4 seconds
Installing different package versions 22 seconds
Running and plotting the test cases 4 minutes and 12 seconds

@aitap
Copy link
Member

aitap commented Jan 18, 2026

According to gcc -fstack-usage, copyVectorElements() now costs 48 bytes per function call, and copyAsPlain() does 32. On master, it's 48 bytes per copyAsPlain(). Maybe the recursive call to copyAsPlain is not so bad, since it shouldn't be on any hot paths, and R asks for a very large stack anyway.

As a minor improvement, it may be worth switching this bit of code from int64_t indices to R_xlen_t.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reduce duplication: growVector() vs. copyAsPlain()?

3 participants