Hacker News new | past | comments | ask | show | jobs | submit login

Nitpick on the nitpick. If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks.

Pretty aggressive stance when you may, in fact, be wrong.




> If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks.

no. Because they are still reading git blobs - just only for the smaller files.

> GitLab no longer loads large Git blobs (e.g. binary files) into memory [emphasis mine]

So if their handling of Git blobs is leaking memory, then not reading the bigger blobs just gives them more leeway before they crash.


Again, you may still be wrong. Many systems have different strategies for large blobs vs. small blobs (I know it's many because I've written several myself) including chunking strategies, separate memory pools etc.

I'm taking this stand because I've had the exact issue we are arguing about: my large file handler had a leak in the memory pool for large blobs. Basically it was shared memory space for multiple processes so large objects could be passed out of band instead of using IO.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: