Chuyện vui VBA (1 người xem)

[ThangCuAnh]

Hì hì, sáng nay cuối tuần rãnh rỗi, ngồi hì hụi làm cái file Excel để minh họa cho chuyện vui. Cái cô kế toán nghỉ nên phải tự tay làm, mà mình thì mới học Ét xèo nữa, nên "thật nà vất vã".
Chuyện như thế này, có 3 nhân vật trong chuyện, 1 là anh Excel, 2 là anh VBA, 3 là anh dùng VBA, hay còn gọi là coder. Một ngày ẹp trời, anh coder viết code và bắt đầu nói chuyện.
- Coder: Ê, Excel, tao cần lấy data từ Range("A1:C10000")
- Excel: Có ngay, mày muốn lấy Value hay Value2
- Coder: Tao muốn lấy Value. Tao thấy mấy người kia xài Value thì tao cũng xài Value, éo thèm đọc "đồ cú mèn" đâu.
- Excel: mẹ, xài sang. Chả có dữ liệu Currency hay DATETIME API mà đòi Value. Thôi, kệ mẹ mày, chờ tao chút, tao chuẫn bị dữ liệu cái. Lầm bầm: phải check, mang theo cái field Currency với record cho nó mà nó éo có dùng, mẹ nó, xài sang.
- Excel: Xong rồi, Value nhen, trả về Variant nhen. Tao ghi rõ trong "đồ cú mèn" rồi đó. Trong ruột Variant tao là array nhen.
- Coder: không được, tao không đọc "đồ cú mèn", thấy người ta dùng array của Variant không à, tao cũng lỡ tay gõ () rồi.
- Excel & Coder: cãi nhau....
- VBA: Thôi can 2 anh, em đứng giữa đây, khổ quá, mọi chuyện đã có em "no".
Và anh VBA phải hì hục cấp mới 1 array của Variant cho anh coder, lấy trong ruột Variant của anh Excel ra cái array, hì hục convert, chép từng thằng phần tử vào cái array của anh coder, rồi lo thêm vụ giải phóng cái Variant Excel trả về nữa cho rộng chỗ.
Cuối cùng chỉ có anh coder hể hả, xong nhiệm vụ, chỉ tội 2 anh Excel và VBA ngồi thở phì phò, lâu mồ hôi, chửi thầm: mẹ, thằng coder nhiều chuyện, đương không thêm cái () vào chi với đòi Value cho mình mệt bỏ xừ, tốn thêm 1 mớ bộ nhớ nữa.

Xong câu chuyện, mời bà con cười cái rồi download file test_Range để chạy kiểm tra câu chuyện và hiểu tại sao thằng VBA với Excel xúm vào chửi thằng coder nhé
Cứ click vô cái nút "ẹp ẹp xanh xanh" ấy rồi chờ chút xong xem kết quả

 

[ThangCuAnh]

Hì hì, like cười cái giề bà con, chuyện hổng có vui đâu. Ai đang dùng () với Value thì sữa lại đi, thành arr không () hay arr as Variant, Value thì chọt thêm số 2 vào.
Lỗi () này hầu như tui để ý thấy ai cũng bị đó, chỉ trừ @snow25
Theo bảng kết quả trong file đã up, các bác có thấy là dùng biến Variant gán bằng Range.Value2 cho ra giá trị thời gian chạy thấp nhất 0, chỉ chiếm hơn 50% 1 chút so với dùng arr() = Range.Value không ?
Nên các bác nên sữa code đã viết lại, thường các bác viết như sau:

Dim SArr()    ' VBA sẽ hiểu SArr là 1 array của các phần tử Variant
SArr = xxxx.Range(xxx).Value

Thành:

Dim SArr As Variant  ' Bỏ () đi, nên khai báo tường minh là Variant
SArr = xxxx.Range(xxxx).Value2

Nếu lấy data sai trong 1 vài trường hợp đặc biệt thì thò ngón tay del số 2 đi thôi
Xong, với file dữ liệu lớn, các bác sẽ thấy tốc độ của code của các bác sẽ tăng lên gần gấp đôi. Hì hì, chỉ là dùng tip nhỏ thôi đó.

 

[ThangCuAnh]

Google thử "Excel Value Value2" ra nhiều phết, thiên hạ cũng đã bàn nhiều. Thấy cái link này làm ra bản test luôn và viết tương đối kỹ:

TEXT vs VALUE vs VALUE2 – Slow TEXT and how to avoid it

I was intrigued by a recent post pointing out that using .Text to retrieve data from Excel ranges got slower and slower as you iterated through the rows. So I took some time to explore and compare …

fastexcel.wordpress.com

 

[ptm0412]

Nên các bác nên sữa code đã viết lại, thường các bác viết như sau:

Dim SArr()    ' VBA sẽ hiểu SArr là 1 array của các phần tử Variant
SArr = xxxx.Range(xxx).Value

Thành:

Dim SArr As Variant  ' Bỏ () đi, nên khai báo tường minh là Variant
SArr = xxxx.Range(xxxx).Value2

Nếu lấy data sai trong 1 vài trường hợp đặc biệt thì thò ngón tay del số 2 đi thôi
Xong, với file dữ liệu lớn, các bác sẽ thấy tốc độ của code của các bác sẽ tăng lên gần gấp đôi. Hì hì, chỉ là dùng tip nhỏ thôi đó.

Gởi ThangCuAnh,
Tôi cũng đọc đâu đó rằng Value2 nhanh hơn Value nên cứ thế mà gõ Value2 mà không hiểu sâu xa bên dưới của nó. Nay nhờ bạn cho 2 anh kia chửi chi tiết nên mới biết (chửi tan nát luôn). Xin cám ơn nhiều

Nhân tiện tôi hỏi thêm: Nếu như tôi khai báo Arr() và vẫn lấy Value2 thì có bị chậm không, hay có bị 2 anh kia chửi không?

 

[ThangCuAnh]

Trong file test có kết quả đó anh.
Nếu anh dùng Arr() thì chỉ mình VBA càm ràm thôi

 

[ptm0412]

Trong file test có kết quả đó anh.
Nếu anh dùng Arr() thì chỉ mình VBA càm ràm thôi

Tôi chạy file test trên máy mình thì có kết quả:

 

[ThangCuAnh]

Chà, xuống tới 60%

 

[ThangCuAnh]

Bị bug bác Tuân làm nhức đầu quá, thôi giải trí chút với em Ét xèo và "Vớ Bở À", sữa lại cái file trên thêm mắm muối chút cho bà con coi, test chơi.
Có thét mét gì thì post lên trao đổi nhé

 

[ptm0412]

Có thét mét gì thì post lên trao đổi nhé

Như vậy khai báo Arr thì lấy dữ liệu lên nhanh hơn khai báo Arr(). Nhưng truy xuất dữ liệu và ghi dữ liệu đối với Arr (có khai báo () ) thì lại nhanh hơn hả bạn?
Vậy rút kinh nghiệm mảng dữ liệu nguồn thì khai báo Variant, mảng kết quả thì khai báo Array() hay sao?
Mảng kết quả thì phải write nên Arr() phải rồi, còn mảng nguồn cũng vẫn phải read, nên tôi nghĩ hay là tùy vào dữ liệu và bài toán cụ thể nhỉ?

 

[Kiều Mạnh]

Tại sao Bill lại bày ra value và Value2 làm chi ko biết ... chắc có ý đồ chi rứa

1/ Trong trường hợp nào sử dụng value tốt nhất ... tại sao ??!!
2/ Trong trường hợp nào sử dụng value2 tốt nhất ... tại sao ??!!

Range.Value property (Excel)

Office VBA reference topic

docs.microsoft.com

Range.Value2 property (Excel)

Office VBA reference topic

docs.microsoft.com

Sub Value_Value2()
    [A1] = Date
    [C1] = [A1].Value2
    [E1] = [A1].Value
    MsgBox "Value doc A1 thanh " & TypeName([A1].Value)
    & vbNewLine & "Value2 doc A1 thanh " & TypeName([A1].Value2)
End Sub

 

[batman1]

Trong trường hợp nào sử dụng Value2?

Nếu ai test thấy Value2 nhanh thì ghi vào sổ tay thôi. Chưa có một ai phủ nhận là Value2 không nhanh. Hãy nhớ lấy điều này để khỏi cãi chầy cối.

Còn dùng Value hay Value2? Thì tùy vào đánh giá của mỗi người thôi.

Không ai chạy code trong vòng lặp 1000 lần cả. Vậy thì ta xét 2 trường hợp, cả 2 chỉ chạy code 1 lần.
1. Dữ liệu "hơi" khủng": 10 000 dòng và 3 cột thôi.
Dùng Value mất 30,4 ms (không viết nhầm nhé - 30,4 ms)
Dùng Value2 mất 15,6 ms. Rõ ràng nhanh hơn 50% nhé. Không ai phủ định điều này cả? Thế thì nhớ để khỏi chầy cối nhé.

2. Dữ liệu cực khủng, tức khoảng hơn 1000 lần so với trường hợp 1: 800 000 dòng, 37 cột. Khủng chưa?
Dùng Value mất 30400 ms (không viết nhầm nhé - 30400 ms)
Dùng Value2 mất 15600 ms. Rõ ràng nhanh hơn 50% nhé. Không ai phủ định điều này cả? Thế thì nhớ để khỏi chầy cối nhé.

Nhưng không ai rỗi hơi load dữ liệu vào mảng rồi kết thúc. Load vào mảng để thao tác: tìm kiếm, cộng trừ nhân chia, làm việc. Cứ cho là việc không "khủng" nên chỉ mất 1 s = 1000 ms cho trường hợp 1 và 1000 s = 1000 000 ms cho trường hợp 2.

Tổng cộng:
1.
Dùng Value mất 1030,4 ms
Dùng Value2 mất 1015,6 ms
Chạy lần lượt 2 code có ai cảm nhận được sự khác biệt 14,8 ms không? Không dùng đồng hồ đo thì thánh cũng không cảm nhận được sự khác biệt.
Và tất nhiên lúc này làm gì có sự chênh lệch giữa 2 thời gian thực hiện ở mức 50%? đánh giá cả quá trình chứ không ai đánh giá 1 khía cạnh cả.

2.
Dùng Value mất 1030400 ms
Dùng Value2 mất 1015600 ms

Chênh nhau ~15 s là nhiều. Nhưng xét ở góc độ khác thì con người không cảm nhận được sự khác biệt giữa 17 phút 10,4 s và 16 phút 55,6 s. Cảm nhận được sự khác biệt giữa vd. 15 s và 30 s, nhưng khó cảm nhận sự khác biệt giữa 17 phút 15 s và 17 phút 30 s. Với khoảng thời gian như thế nếu không nhìn đồng hồ thì con người còn không biết đã hết 15 phút hay hết 17 phút.

Đấy là đang tính việc làm bình thường với mảng chỉ hết 1 s. Nếu mất 2 s thì sự khác biệt giữa
2 s 30,4 ms và 2 s 15,6 ms hoặc 33 phút 50,4 s và 33 phút 35,6 s lại còn "thê thảm" hơn nữa.

Tùy theo sự đánh giá, sự cải tiến nó ở mức hàng trăm, hàng chục hay thậm chí hàng đơn vị hay chỉ ở mức hàng "phần nghìn", hàng "phần triệu". Nhanh hơn vài ms cũng là nhanh. Vấn đề ở chỗ nó có đáng với công việc đang làm không. Không có chuyện code đang chạy chậm tới mức phải ra ngoài hút thuốc, uống cà phê, rồi chỉ cần đô la hay Value2 là tự nhiên chỉ còn ở mức chưa kịp chớp mắt. Đô la và Value2 không thể cho sự cải thiện vượt bậc như thế. Nhưng cùng một việc thì công thức dở, code dở có thể chạy ở mức "ra ngoài uống cà phê", còn công thức tối ưu, code tối ưu có thể chạy ở mức "chưa ngáp xong". Khả năng cải thiện của $ và Value2 nó ở cỡ đó thôi, không cố rặn ra nhiều được.

Tất nhiên viết hệ điều hành thì người ta "chắt chiu" từng nhịp đồng hồ CPU đấy. Chỉ có điều không ai viết hđh bằng VBA cả (VB). Và cũng chả ai dùng mấy hàm đô la hay Value2 cả. Ví dụ trật lất, chỉ là cố tình chầy cối mà thôi.

Mỗi người tự đánh giá xem ở trường hợp cụ thể thì mức độ cải thiện là đáng kể hay chỉ tủn mủn. Mỗi người có quyền lựa chọn. Và sẽ chả ai có quyền áp đặt sự lựa chọn của mình lên người khác.

Riêng tôi luôn cho rằng thuật toán hay và thuật toán dở khác nhau một trời một vực về thời gian thực hiện. Còn mấy trò $, Value2 cũng cho cải thiện nhưng chỉ ở mức độ không đáng màng tới.

Nhân chuyện vui nhớ lại chuyện mới đọc trên báo Ba Lan, dân mạng được dịp ném đá thoải mái. Có ông quan nọ, quan thì ở đâu cũng có nhưng đây là ông quan liêu ở bộ phận quản lý một khu nhà. Có anh A trả tiền nhà sau thời hạn 5 ngày, vậy anh ta tự tính lãi trả chậm theo qui ước của pháp luật và thêm vào tiền nhà. Nhưng anh ta làm tròn. Kết quả là thiếu 30 xu. Ông quan liêu nhất định bắt anh A trả, không thể cho 30 xu vào mục thất thoát, cũng không muốn làm tròn xuống như anh A được. Kết quả là ông gửi thư báo cho anh A. Phí tổn cho phong bì và tem là 350 xu. Không kể công người gửi thư, người đưa thư, công của anh A, riêng phí tổn là 350 xu. Cơ quan ông quan tính ra bị âm 320 xu. Ông quan làm cũng không sai về luật nhưng là ông quan cứng nhắc, âm cũng được nhưng quyết đòi bằng được. Trong cuộc sống thì những ông quan kiểu này chỉ làm hại cơ quan, và làm khổ dân đen. Và mạng lại dậy sóng, chửi thầm: "Cha mẹ thằng quan liêu, ngu không biết tính thiệt hơn, chỗ hoang phí tiền tỷ thì không "nhìn" ra mà lại chỉ chăm chăm vào cái tủn mủn. Xã hội kiểu này thì mãi sẽ không khá lên được."

Cô gái nào đi lấy chồng cũng sợ gặp phải mẹ chồng kiểu "đo lọ nước mắm, đếm củ dưa hành" . Trong cuộc sống mà gặp những vị "đo lọ nước mắm, đếm củ dưa hành" thì rất rách việc. Và người người lại chửi thầm: "Cha mẹ thằng chắt chiu từng hạt muối hạt vừng ............. không đúng chỗ"

Còn ta thì nghĩ rằng: Chả thèm mất thời gian cho những trò nhí nhố đó làm gì. Khi nào, trong trường hợp cụ thể, có dữ liệu cực cực khủng và xét thấy có sự cải tiến RÕ RỆT thì lúc đó mới đắn đo đô la hay euro. Còn không đô hay êu đều được.

Cảm nhận của riêng tôi thôi. Việc dùng gì là sự lựa chọn của mỗi người. Tôi không ép ai, thậm chí không nài nỉ ai phải dùng cái này hay cái kia.

 

[SA_DQ]

. . .Kết quả là ông gửi thư báo cho anh A. Phí tổn cho phong bì và tem là 350 xu. Không kể công người gửi thư, người đưa thư, công của anh A, riêng phí tổn là 350 xu. Cơ quan ông quan tính ra bị âm 346 xu. . . .

Xét về khía cạnh kinh tế thì ông này mất thêm vài calo để tính toán ra con số 4 xu đó & vài calo để trả cho việc gởi thư báo nợ,. . .
Nhưng những mất mác đó đã có 'Nhà nước' lo
Ô. ta được tiếng là mẫn cán với công việc & thời đại 4.0 thường các sếp iêu cầu cấp dưới sẽ phải làm việc như máy
Như vậy hành vi này của ông ta sẽ được ghi nhận trong kỳ xét lương tiếp theo gần nhất!
Về mặt xã hội mà nói: Hành vi ông này đã giúp ích trong việc chu chuyển dòng tiền (350 + 4) trong XH cỡ trên 3 xu gì đó lãi xuất!
Tóm lại XH chỉ mất 1 xu thôi & chuyện đó đáng mất trong 1 XH thượng tôn pháp luật như VN, /(ha, Kha, kha,. . . .

& chúc mọi người vui vẻ trong ngày!

 

[batman1]

Tôi thì nhiều khi cũng trả chậm nhưng nếu tính tiền lãi chậm mà phần cuối là vd. 5 500 thì tôi bao giờ tôi cũng làm tròn lên 10 000. Làm tròn lên 6 000 là được nhưng 4 000 nó là gì đâu. 1 cốc trà đá. Nhiều khi gặp người khốn khó thì tiền triệu cũng chả tiếc huống chi vài nghìn. Làm chẳng qua để tránh được những vị quan cứng nhắc thôi. Một xu cũng là tiền nhưng rất nhiều người đánh rơi mà không muốn cúi xuống nhặt. Thôi thì cho ai đó nhặt được. Với họ cũng chả là tài sản quí giá nhưng nó là "cái may". Tuy nhiên có người thấy 1 xu là phấn khích ngay. Lợi 1 xu nhé. Hôm nay thất nghiệp, không làm được 1 xu, vậy lãi 100% nhé. Hóc môn trong người sôi sùng sục, sự hưng phấn đạt đỉnh điểm vì "1 xu cũng là tiền". Lãi hẳn 100% chứ đâu chỉ 50% quèn.

 

[ThangCuAnh]

@kieu manh: Value và Value2 có lịch sử từ xa xưa rồi, từ những ver đầu của Excel. Hồi đó, Value2 chính là Value, không có Value2. Nhưng theo sự phát tiển của xã hội, tiền của tỷ phú đô la và các giao dịch tăng lên, nên mới đẻ ra thêm vụ datatype là Currency. Chứ như cỡ Rockerfeller hồi đó thì vài trăm triệu đô đã giàu nhất thế giới rồi. Chứ giờ như bác Bill thì lấy số tiền của bác ấy, cho 100 tỷ USD đi, * 23, 24 ngàn Vê Nờ Đê thử xem, số nào có thể chứa được ? Nếu không phải là currency ?
Vụ datetime cũng vậy, trên Windows nhiều kiểu dữ liệu datetype lắm, Windows datetime, DOS datetime, Unix datetime... Từ tàn tích từ DOS lên, từ OS2 qua. Team Windows kernel đầu tiên được MS dụ hết về MS từ OS2. Hình như là Dave Cutler lead team, Helen gì đó làm phó, lâu quá quên rồi. Họ có cùng viết cuốn "Inside Windows NT" đầu tiên, rất nổi tiếng, giờ tuyệt tích rồi. Giải thích rất rõ về HĐH WinNT.
Team Excel phải hy sinh tốc độ và bộ nhớ cho yêu cầu mới này, cũng do ông "Vớ Bở À" lanh chanh, la khó thao tác với các kiểu datetime của Windows quá, nên mới sinh ra cái vụ từ datetime Windows qua kiểu double cho ông dở hơi "Vớ Bở À" này.

@ptm0412: Anh test thử hết các cột 1, 2, 3 chưa, và có xem code vụ Debug.Print address không ?
Hì hì, chưa xong đâu anh, còn 2 bước nữa lận. Đầu tiên chúng ta đã có read lên, kế là thao tác với data đã read.
Giờ còn bước 3 là làm thống kê viết ngược lại, dập xuống. Với các trường hợp sau:
Range.Value = arrV()
Range.Value2 = arrV()
Range.Value = vArr
Range.Value2 = vArr
Anh làm thống kê đi nhé, mình tui làm chán "nắm nuôn"
Tiếp còn bước 4, anh làm thống kê từ hết 3 bước trên, từng kiểu dữ liệu, xem và rút ra kết luân khi nào dùng, dùng như thế nào....

 

[Kiều Mạnh]

Hóng dòng sau:
Tiếp còn bước 4, anh làm thống kê từ hết 3 bước trên, từng kiểu dữ liệu, xem và rút ra kết luân khi nào dùng, dùng như thế nào....

 

[ThangCuAnh]

Hì hì, không có gì là tuyệt đối, ông trời không cho không cái gì cả. Được này mất khác, có cái này mất cái kia. Bạn @kieu manh ơi.
Ví dụ vụ mua máy mới để giải quyết bài toán Excel chậm. Mua máy xịn thì tốn tiền, mà mai sau dữ liệu phình ra nữa thì lại mua máy mới à ? Tốn tiền nhưng được cái quăng vô là chạy, khỏi lăn tăn...
Nếu tiếc tiền, không đủ tiền thì tự học tự làm lại công thức, tổ chức trình bày file lại, học viết code VBA. Tiết kiệm được tiền nhưng phải mất thời gian, công sức, chứ có sẵn đâu. Nhưng được cái học được nhiều, có kinh nghiệm cho lần sau. Nhưng lại không được cái là nhiều khi tốn thời gian so với tháng lương của anh ta có đáng không ?
Nên vậy phải trung dung, không chọn 1 hoặc 2, mà nên ít 1, ít 2. Tùy người, tùy cảnh.
Tui thì tui chọn cách 2, để tiền đi nhậu, kkk

Còn 1 cách nữa quên nói: là đặt viết phần mềm hay mua phần mềm có sẵn. Mà tùy giá tiền đã, cao hơn mua máy không ? Không thì pm viết có chưa, có rồi thì mua, mà thường thì pm viết sẵn nó viết chung chung, hầu như không bao giờ khớp với nhu cầu người dùng. Muốn khớp thì phải bỏ thêm tiền cho nó "may đo" theo nhu cầu mình. Cái này thì rườm rà, mất thời gian "nắm nắm nuôn"
Còn chưa có pm có sẵn thì tìm cty viết pm uy tín, giá rẽ đã. Cái này cũng mất thời gian. Rồi khảo sát, ký hợp đồng, chờ viết, dùng thử, phản hồi yêu cầu mới, thay đổi, fix bugs, bảo hành...Ôi chao, vô vàn vấn đề, thời gian, mà thường thì cuối cùng thì 2 bên phải: kệ, vậy được rồi, chấp nhận vậy đi....hay 1 bên bỏ cuộc, chạy làng, kkk.
Hì hì, vì hồi xưa cty mình làm có nhánh pm trong nước mà, lỗ quá, không sinh lời, phiền phức kéo dài quá nên cuối cùng teo dần, teo dần rồi chết luôn
Tới giờ làm pm trong nước vẫn khó ăn

 

[ptm0412]

Anh làm thống kê đi nhé, mình tui làm chán "nắm nuôn"
Tiếp còn bước 4, anh làm thống kê từ hết 3 bước trên, từng kiểu dữ liệu, xem và rút ra kết luân khi nào dùng, dùng như thế nào....

Thật ra tôi cũng suy xét và có nghĩ như anh batman: Value2 nhanh gấp đôi nhưng phải kết hợp với khai báo variant. Và cũng chỉ là nhanh cho bước mở đầu (có mấy phần trăm của toàn bộ thời gian),
It nhất còn 1 bước đọc (read) và bước ghi vào kết quả (write). Hai bước này theo file thứ hai của bạn thì nó đã bù trừ gần hết cho cái nhanh của variant rồi.
Sau đó còn phải kể đến bước giữa: đọc xong còn phải xử lý tính toán các loại mới có kết quả mà ghi chứ? Bước này mới chiếm nhiều thời gian, thậm chí 80% tổng thời gian nếu như phải xử lý chuỗi. Vậy thì như anh batman nói: 10.5 giây và 10.7 giây có khác là bao?
Cải thiện thuật toán có thể cần tiết kiệm 1 ms cho 1 vòng lặp, vì ta sẽ có hàng ngàn, chục ngàn vòng lặp. Nhưng đó lại là chuyện cải thiện thuật toán chứ không còn là vấn đề của mảng variant hay không variant nữa.

 

[Kiều Mạnh]

Nghiên cứu mà cải tiến được cái gì thì cứ làm mỗi cái nhanh 1 chút cộng lại là ok... và quan trọng là ta hiểu được bản chất sâu xa của nó mà có hướng phát triển tốt hơn vv

 

[ThangCuAnh]

Hì hì, anh ptm0412 cứ làm tiếp thống kê với ghi ngược lại data vào Range.Value/Value2.
Như trong bài toán bên kia của cô gái xinh ẹp OverTime thì cái vòng xữ lý dữ liệu nó chiếm chưa tới 1/3 thời gian của toàn hàm, read from Range và write to Range mới là cái cuối cùng nặng nhất. Không biết anh có download về xem chưa ?
Về vụ optimize thì còn nhiều, rất nhiều cái để viết nữa, mà tui lười, không hứng viết tràng giang đại hải,đọc phát mệt nên từ từ viết chút chút.

 

[ptm0412]

Về vụ optimize thì còn nhiều, rất nhiều cái để viết nữa, mà tui lười, không hứng viết tràng giang đại hải,đọc phát mệt nên từ từ viết chút chút.

Về vụ optimize thì có 1 thí dụ như sau:
Giả sử có 1 dữ liệu khủng 500 ngàn dòng và phải duyệt qua 500 ngàn dòng đó để lấy 1 số kết quả thỏa điều kiện gì đó (khoảng 10 ngàn dòng kết quả). Nếu dữ liệu hổ lốn thì bắt buộc phải vét cạn cả bằng ấy dòng. Tuy nhiên nếu điều kiện "gì đó" liên quan đến việc sort dữ liệu thì tôi sẽ bỏ 1 miếng thời gian sort dữ liệu trước, sau đó khi không còn thỏa điều kiện tôi thoát ra. Vậy thì tôi tiết kiệm được 490 ngàn vòng lặp. Đây mới là sự tiết kiệm đáng kể