Skip to main content
Fix broken link
Source Link
Flux
  • 10.7k
  • 6
  • 56
  • 103

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.htmlRe: serious performance issues with images, audio files, and other "non-code" data:

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response from Re: serious performance issues with images, audio files, and other "non-code" data:

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

Restore the semantics of the original code. Nobody will lose important data if they copy/paste without thinking/reading.
Source Link
hdorio
  • 13.2k
  • 5
  • 36
  • 35

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' >>> .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' >> .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

Change `>` to `>>` to avoid data loss for people copy-pasting the command and tweak formatting.
Source Link
Joachim Sauer
  • 306.5k
  • 59
  • 561
  • 617

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' >>> .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

core.compression 0 # Didn't seem to work.

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

pack.window 0

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

echo '*.jpg -delta' > .gitattributes

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

core.compression 0 # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

echo '*.jpg -delta' > .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

The time problem I had was caused by delta compression.

The solution for me was

echo '*.zip -delta' >> .gitattributes
git gc

I will quote this excellent response from http://lists-archives.com/git/719515-serious-performance-issues-with-images-audio-files-and-other-non-code-data.html

Git does spend a fair bit of time in zlib for some workloads, but it should not create problems on the order of minutes.

For pushing and pulling, you're probably seeing delta compression, which can be slow for large files

 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects within packfiles. It can save a little time for objects which won't compress, but you will lose the size benefits for any text files.

But it won't turn off delta compression, which is what the "compressing..." phase during push and pull is doing. And which is much more likely the cause of slowness.

 pack.window 0

It sets the number of other objects git will consider when doing delta compression. Setting it low should improve your push/pull times. But you will lose the substantial benefit of delta-compression of your non-image files (and git's meta objects). So the "-delta" option above for specific files is a much better solution.

 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.

replace broken link
Source Link
hdorio
  • 13.2k
  • 5
  • 36
  • 35
Loading
Rollback to Revision 2 - Edit approval overridden by post owner or moderator
Source Link
hdorio
  • 13.2k
  • 5
  • 36
  • 35
Loading
Added note clarifying that the settings have to be done on the source, not the target repo
Source Link
Loading
Source Link
hdorio
  • 13.2k
  • 5
  • 36
  • 35
Loading