4 ms·

I also cannot explain it. If I was a dev on a system that had a 6 minute loading time, I'd be stopping what I was supposed to be doing and debugging it after a

by spuz 3y ago

I also cannot explain it. If I was a dev on a system that had a 6 minute loading time, I'd be stopping what I was supposed to be doing and debugging it after a couple of days of suffering through it.

DANmode 3y ago
That's the fun part: their dev systems almost certainly are not console dev kits, or consumer PCs. They're absolutely jacked workstations that probably loaded it in a blazing 2.7 minutes!
- charles_f 3y ago
  Or even simpler, they have flags to deactivate loading that catalog, so the issue doesn't exist for them
  - spuz 3y ago
    But if that's true, then there's even less excuse for not fixing the bug because it would imply at least one person knew the slow loads were caused by loading a small 10MB json file.
    - Verdex 3y ago
      Maybe, but not necessarily. The devs may even have been begging to fix it, but project management kept prioritizing other items in the backlog. If there's a million fires and half of those crash the game, fixing something like a load time might easily stay under the radar. And that's even before we consider internal political issues. The code could have been owned by a group that was refusing any PRs that would have fixed the issue. Or maybe the code was written by the big boss' nephew and fixing it would have removed his contribution.
      - charles_f 3y ago
        Yeah there's definitely a scenario where the guideline was "let's hit the deadline, we'll fix it after"
charles_f 3y ago
I started working on a codebase where the git repo is 56gb. Turns out that it's a bunch of binary files that were committed and updated a buncha times more than 2y ago. They're not even in the main branch anymore. Nobody in the main team working on that seem to have cared enough to fix it before. Don't underestimate the power of complacency
- DistractionRect 3y ago
  It's kinda careless to rewrite history just because a repo is large. Any reason you aren't doing a partial/shallow clone?
  - charles_f 3y ago
    Why though? I understand the point of keeping some history, but what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. And then, you can still keep a full version of the history in another repo if you really have auditing requirements that mandate keeping history forever.
    - DistractionRect 3y ago
      > what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. If you extend the logic, what's the point of keeping any commits from years ago? What's a good cut off date to just start discarding history? Rewriting it? But in the same breath, what's the point of cloning commits from years ago? It's not as if you'd cherry pick anything from back then. And that's my point, the former requires an org decision and active action, and the other is a blobless clone. The nice thing about the blobless clone is you can always change your mind, you can get old blobs if you find you need it. But if you threw out old commits, and you need them later... that's the brakes.

by spuz 3y ago

I also cannot explain it. If I was a dev on a system that had a 6 minute loading time, I'd be stopping what I was supposed to be doing and debugging it after a couple of days of suffering through it.

DANmode 3y ago

That's the fun part: their dev systems almost certainly are not console dev kits, or consumer PCs. They're absolutely jacked workstations that probably loaded it in a blazing 2.7 minutes!

charles_f 3y ago
Or even simpler, they have flags to deactivate loading that catalog, so the issue doesn't exist for them
- spuz 3y ago
  But if that's true, then there's even less excuse for not fixing the bug because it would imply at least one person knew the slow loads were caused by loading a small 10MB json file.
  - Verdex 3y ago
    Maybe, but not necessarily. The devs may even have been begging to fix it, but project management kept prioritizing other items in the backlog. If there's a million fires and half of those crash the game, fixing something like a load time might easily stay under the radar. And that's even before we consider internal political issues. The code could have been owned by a group that was refusing any PRs that would have fixed the issue. Or maybe the code was written by the big boss' nephew and fixing it would have removed his contribution.
    - charles_f 3y ago
      Yeah there's definitely a scenario where the guideline was "let's hit the deadline, we'll fix it after"

charles_f 3y ago

I started working on a codebase where the git repo is 56gb. Turns out that it's a bunch of binary files that were committed and updated a buncha times more than 2y ago. They're not even in the main branch anymore. Nobody in the main team working on that seem to have cared enough to fix it before. Don't underestimate the power of complacency

DistractionRect 3y ago
It's kinda careless to rewrite history just because a repo is large. Any reason you aren't doing a partial/shallow clone?
- charles_f 3y ago
  Why though? I understand the point of keeping some history, but what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. And then, you can still keep a full version of the history in another repo if you really have auditing requirements that mandate keeping history forever.
  - DistractionRect 3y ago
    > what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. If you extend the logic, what's the point of keeping any commits from years ago? What's a good cut off date to just start discarding history? Rewriting it? But in the same breath, what's the point of cloning commits from years ago? It's not as if you'd cherry pick anything from back then. And that's my point, the former requires an org decision and active action, and the other is a blobless clone. The nice thing about the blobless clone is you can always change your mind, you can get old blobs if you find you need it. But if you threw out old commits, and you need them later... that's the brakes.