Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge memory allocation with a big log file. #256

Closed
blastmann opened this issue Feb 26, 2024 · 2 comments
Closed

Huge memory allocation with a big log file. #256

blastmann opened this issue Feb 26, 2024 · 2 comments
Labels
duplicate This issue or pull request already exists

Comments

@blastmann
Copy link

I try to debug xcbeatify with a 250MB xcode build log file.

After running a moment, memory allocation is up to 1.1GB above. I think that is not a proper memory consumption.

image

So I dig into the memory allocation of this situation, there is a while-loop in Xcbeatify.swift without autoreleasepool.

Maybe we should consider to add a proper autoreleasepool in order to keep a low memory level like this:

image
@cpisciotta
Copy link
Owner

Hi @blastmann! I released two new versions of xcbeautify yesterday.

  • 1.5.0 should resolve your problem (also reported by Severe memory usage #162). You can see the performance tests here.
  • 1.6.0 introduces SwiftCompile support. You should see more accurate logs, since we're capturing the output; the logs should also be much faster, since we're no longer looping through each regex. You can see the performance tests here.

I tried your suggestion, using autoreleasepool, with the latest release, but I'm not seeing any significant differences in memory consumption.

This is not to say there aren't additional areas for improvement, but I think you'll notice notable improvements with the recently released versions. Let me know!

@cpisciotta cpisciotta added the duplicate This issue or pull request already exists label Feb 26, 2024
@blastmann
Copy link
Author

Hi @cpisciotta. So glad to see there is a huge performance improvement.

I test the memory consumption with the newest code and it doesn't easy to reproduce this issue any more.

Using autoreleasepool in loop is some kinds of best practise of performance optimization and release memory ASAP.

Maybe we should consider using it in this situation. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants