2010-11-16 1 views
25
$ time __git_ps1 
((v2.6.33.4)) 
real 0m1.467s 
user 0m0.864s 
sys 0m0.564s 

Làm cho lời nhắc của tôi không sử dụng được; mặt khác, mặc dù, nó quá hữu ích một tính năng để từ bỏ nhẹ. Bất kỳ ý tưởng tại sao nó chạy quá chậm và những gì tôi có thể làm gì về nó?__git_ps1 cực kỳ chậm trong hạt nhân

chi tiết Setup:

$ uname -a 
Linux martin-laptop 2.6.35-22-generiC#35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux 

$ git --version 
git version 1.7.1 

$ du -sh . 
876M . 

tôi nghi ngờ điều gì đó với máy tính của tôi kể từ khi trên hộp đồng nghiệp của tôi, trong cây hạt nhân tôi được nhân bản từ, trở về lệnh cùng ngay lập tức

$ time __git_ps1 
((v2.6.33.4)) 
real 0m0.039s 
user 0m0.008s 
sys 0m0.016s 

thêm đầu ra hdparm:

mine

$ sudo hdparm -tT /dev/sda4 

/dev/sda4: 
Timing cached reads: 1542 MB in 2.00 seconds = 772.35 MB/sec 
Timing buffered disk reads: 110 MB in 3.02 seconds = 36.42 MB/sec 

đồng nghiệp của

$ sudo hdparm -Tt /dev/sda6 

/dev/sda6: 
Timing cached reads: 1850 MB in 2.00 seconds = 926.03 MB/sec 
Timing buffered disk reads: 210 MB in 3.02 seconds = 69.53 MB/sec 

khác biệt khác: đồng nghiệp đang chạy git 1.6.5, tôi đang chạy 1.7.1

+0

Bạn đang chạy hệ điều hành nào? Kho lưu trữ của bạn lớn đến mức nào? –

+0

điểm tốt, tôi đã thêm chi tiết thiết lập vào bài –

+0

là nó chỉ chậm lần đầu tiên, hoặc là các cuộc gọi tiếp theo để '__git_ps1' tương ứng' git status' chậm quá? có thể là sự cố bộ nhớ đệm. (trên máy của tôi cuộc gọi đầu tiên thực sự chậm, sau đó nó nhanh) – knittl

Trả lời

20

Nó bật ra được một sự kết hợp của hai yếu tố:

Tôi đã sử dụng

export GIT_PS1_SHOWDIRTYSTATE=true 
export GIT_PS1_SHOWUNTRACKEDFILES=true 

theo mặc định. được chứng minh là không sử dụng được trên cây có kích thước hạt nhân. Việc xóa các tùy chọn này sẽ xóa một chút chức năng đẹp từ __git_ps1, nhưng ít nhất nó sẽ trả về ngay lập tức ngay bây giờ. (Bài học hữu ích - thử nội dung từ tài khoản người dùng mới tạo trước bất kỳ tài khoản nào khác.)

Ngoài ra, đĩa cứng trên máy của tôi chỉ đơn giản là chậm, do đó không phải vấn đề git; đây chỉ là lần đầu tiên nó thực sự phản đối khi tôi nhận được thông báo của tôi.

+4

bạn có thể sử dụng 'git config --global bash.showDirtyState true' và ghi đè lên cây này chỉ với' git config bash.showDirtyState false'. Không có cài đặt như thế này đối với các tập tin không được theo dõi (trên git 1.7.3.2) nhưng nó phải dễ dàng để thực hiện điều đó cũng như –

+0

cảm ơn, đó là hữu ích! –

+0

+1: Điều này hóa ra là lý do cho sự chậm chạp của dấu nhắc lệnh ngay cả khi làm việc với các kho lưu trữ khá nhỏ. –

1

bạn có thể thử phiên bản của tôi về git PS1 là nó nhanh hơn hoặc đều chậm?

+0

nó thậm chí còn chậm hơn. Tôi nghi ngờ một cái gì đó với git nói chung vào thời điểm này, kể từ khi tình trạng git quá đang dùng con đường dài hơn nó nên –

+0

bạn đã cố gắng để gọi "git gc" – mpapis

+0

có, nó đã không tạo sự khác biệt. –

1

thế nào về việc cập nhật git-completion.bash đến mới nhất từ ​​ http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/completion;h=525eddf7e4c03acc7b3f01f09f45515cf63cd9b4;hb=master

Là vấn đề địa phương để repo kernel này hoặc nói chung?

git fsck --full có hiển thị gì không?

+0

git-completion.bash mới nhất không giúp ích gì. nó cũng có vẻ là địa phương cho hạt nhân, nhưng tôi không có gì khác so với kích thước để kiểm tra nó với. sẽ để lại git fsck --full chạy khi tôi rời khỏi và xem nếu nó đã bật lên bất cứ điều gì vào buổi sáng, mặc dù tôi nghĩ rằng repo là tốt vì nó là một bản sao từ repo làm việc trên hộp đồng nghiệp của tôi. –

+0

và git fsck --full không tìm thấy bất kỳ vấn đề nào. –

+2

sao chép một repo hạt nhân từ kernel.org và xem vấn đề có hiện diện ở đó không. Nếu đó là ok, repo cũ của bạn có thể bị hỏng một cách kỳ lạ. Một cách tiếp cận khác là sử dụng "strace" trên trạng thái git để xem điều gì đang xảy ra. Có lẽ một khác biệt với đầu ra strace trên máy trường cao đẳng của bạn. –

3

Repo có submodules không? Xem nhận xét về "git status tại là rất chậm" (với môđun con) trong this post, do sự thay đổi được giới thiệu trong 1.7.0:

Việc sửa chữa/công việc xung quanh là phải vượt qua "--ignore-submodules" thành "git status", như lưu ý trong phần cập nhật bên dưới phần: "Cập nhật: Nhờ VonC, người chỉ ra trong các bình luận bên dưới rằng trong git 1.7.2 bây giờ có một tùy chọn" -ignore-submodules "để trạng thái git có thể khôi phục lại hành vi cũ và cung cấp tùy chọn hữu ích chỉ thay đổi các tệp (không phải các tệp không được theo dõi) khiến cho mô-đun con được hiển thị dưới dạng bẩn. "

+0

Cây đầy đủ chắc chắn không có mô-đun con. – Cascabel

+0

được nâng cấp lên 1.7.3 và dùng thử --ignore-submodules, nhưng không hiệu quả. thử 1.6.6 ngay bây giờ. –

+0

1.6.6 cũng không giúp được: ( –

7

để biết được nơi chính xác này cần có thời gian bạn có thể làm:

bash -x

sau đó

__git_ps1

Mine đã dành thời gian cho

++ git ls-files --others --exclude-standard 

nó đã liệt kê tất cả các tệp của drectory nhà gitted của tôi. ngay cả trên một ssd nhanh, phải mất khá nhiều thời gian.

+1

mẹo hay, cảm ơn! hóa ra điều tương tự là dành thời gian cho tôi. –

4

Để sửa lỗi này chỉ cần thêm này trong .bashrc của bạn

export GIT_PS1_SHOWDIRTYSTATE= 
export GIT_PS1_SHOWUNTRACKEDFILES= 

sẽ vô hiệu hóa một số tác phẩm trông-up.

+0

Vâng, đó là những gì tôi đã làm. –