Dictionary & Collection ? (1 người xem)

Liên hệ QC

Người dùng đang xem chủ đề này

Hoàng Nhật Phương

Thành viên gắn bó
Tham gia
5/11/15
Bài viết
1,895
Được thích
1,219
Xin chào các Bạn,
Đầu xuân chúc mọi người luôn mạnh khỏe & bình an.
----
Như tiêu đề OT đã nêu, OT có đọc bài viết của Bạn Collection @befaint nhưng có lẽ do kiến thức còn hạn hẹp nên chưa thể hiểu hết về sự khác biệt giữa Dictionary & Collection,
Ví dụ trong 2 đoạn code dưới đây sử dụng Dictionary & Collection cho cùng một công việc:
Mã:
Option Explicit

Sub CollectionFilter()
Dim TT As Double
TT = Timer
Dim myCol As Collection
Set myCol = New Collection
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If KeyExists(myCol, sKey) = False Then
                j = j + 1
                myCol.Add j, sKey
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            Else
                Result(myCol.Item(sKey), 4) = Result(myCol.Item(sKey), 4) + ArrData(i, 3)
             End If
        End If
    Next i
    If j > 0 Then
        .Range("M2").Resize(100, 4).ClearContents
        .Range("M2").Resize(j, 4) = Result
        .Range("Q7") = Timer - TT
    End If
End With


End Sub


Sub DictionaryFilter()
Dim TT As Double
TT = Timer

Dim Dic As Object
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long
Set Dic = CreateObject("Scripting.Dictionary")
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If Not Dic.Exists(sKey) Then
                j = j + 1
                Dic.Add sKey, j
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            Else
                Result(Dic.Item(sKey), 4) = Result(Dic.Item(sKey), 4) + ArrData(i, 3)
            End If
        End If
    Next i
    If j > 0 Then
        .Range("H2").Resize(100, 4).ClearContents
        .Range("H2").Resize(j, 4) = Result
        .Range("L7") = Timer - TT
    End If
End With

End Sub
Trên máy tính của OT có vẻ như Collection nhanh hơn Dictionary :
1613618736712.png

Nhờ các bạn chỉ dẫn cho OT hiểu rõ thêm trong trường hợp nào thì dùng cái nào sẽ tối ưu hơn?
Tại sao Collection nhanh hơn Dictionary mà không thấy mọi người sử dụng Collection mà thường sử dụng Dictionary hơn hay do thói quen ạ?
 

File đính kèm

Lần chỉnh sửa cuối:
...Ví dụ trong 2 đoạn code dưới đây sử dụng Dictionary & Collection cho cùng một công việc:
Công việc gì?

...Nhờ các bạn chỉ dẫn cho OT hiểu rõ thêm trong trường hợp nào thì dùng cái nào sẽ tối ưu hơn?
Tối ưu là chuyện tương đối.
Chạy ra ga-ra xem một đống xe. Xong về hỏi "cái nào tối ưu?"
Đầu tiên hết, phải biết (giả sử chỉ để đi dạo phố, không phải xe chở hàng):
- ngân sách chi tại chỗ
- ngân sách chi định kỳ (bảo dưỡng, sửa chữa)
- nhà có mấy người
- bao lâu đi Đà lạt, Nha trang một lần (Vũng tàu, Long hải coi như gần, không kể)
...

Tại sao Collection nhanh hơn Dictionary mà không thấy mọi người sử dụng Collection mà thường sử dụng Dictionary hơn hay do thói quen ạ?
Nếu có Méc-sơ-đéc (đọc theo mới là mợt-sí-đì), còn ai muốn đi Ki-a hôn?
Vả lại, tốc độ còn tùy thuộc vào cách sử dụng và dữ liệu.
 
Upvote 0
Hiểu đơn giản nhất thì collection là tập hợp (y như cái tên gọi của nó). Còn dictionary là một dạng tập hợp các phần tử mang cặp giá trị [key-value], với key là duy nhất còn value trùng cũng chả sao. Key của dictionary y như khóa chính trong bảng CSDL vậy.

Ý niệm tập hợp khá tổng quát. Chẳng hạn tôi coi một bảng dữ liệu là tập hợp các record (row). Nhờ cách hiểu này mà sau này tôi tìm hiểu document-oriented database thì hầu như không quá khó khăn dù nó khác xa các dùng relational-database.
 
Upvote 0
Dạ, Bác đây rồi }}}}}
Công việc là công việc là cùng công việc lọc dữ liệu như trong tập tin và trong hình ảnh con gửi kèm Bác ơi.
Bài đã được tự động gộp:

Hiểu đơn giản nhất thì collection là tập hợp (y như cái tên gọi của nó). Còn dictionary là một dạng tập hợp các phần tử mang cặp giá trị [key-value], với key là duy nhất còn value trùng cũng chả sao. Key của dictionary y như khóa chính trong bảng CSDL vậy.

Ý niệm tập hợp khá tổng quát. Chẳng hạn tôi coi một bảng dữ liệu là tập hợp các record (row). Nhờ cách hiểu này mà sau này tôi tìm hiểu document-oriented database thì hầu như không quá khó khăn dù nó khác xa các dùng relational-database.
Cảm ơn Bạn nhiều,
OT cũng hay đọc nhiều bài viết của Bạn và cảm nhận rằng Bạn cũng thuộc top 'siêu cao thủ' về code.
Nếu Bạn hiểu rõ về 2 cái này , phiền Bạn có thể ví dụ cho OT biết trường hợp nào không thể sử dụng Dictionary mà buộc phải sử dụng Collection và ngược lại được không?
Có ví dụ và kèm theo code thì OT sẽ dễ hiểu hơn, chứ với OT mà nói chuyện lời lẽ về code thì như nước đổ lá khoai (@$%@
 
Upvote 0
Tại sao Collection nhanh hơn Dictionary mà không thấy mọi người sử dụng Collection mà thường sử dụng Dictionary hơn hay do thói quen ạ?
Có cái khác 'ngon' hơn thế nữa là đằng khác.
Chuyện thử nghiệm phải phân định các trường hợp của dữ liệu đầu vào để thử nghiệm:
- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
- Add nhiều keys có tỉ lệ trùng 30-50-90%... <--- trường hợp hỗn hợp.
- Còn trường hợp kiểu dữ liệu của key: Number, String. Cái này Dictionary còn mệt nữa.

Việc Add key là công việc rất nặng nề, sau một thời gian thử nghiệm thấy Dictionary rất đuối.
 

File đính kèm

Upvote 0
Có cái khác 'ngon' hơn thế nữa là đằng khác.
Chuyện thử nghiệm phải phân định các trường hợp của dữ liệu đầu vào để thử nghiệm:
- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
- Add nhiều keys có tỉ lệ trùng 30-50-90%... <--- trường hợp hỗn hợp.
- Còn trường hợp kiểu dữ liệu của key: Number, String. Cái này Dictionary còn mệt nữa.

Việc Add key là công việc rất nặng nề, sau một thời gian thử nghiệm thấy Dictionary rất đuối.
Xin chào @befaint cảm ơn Bạn nhiều (người đã mang lại sự băn khoăn cho OT về vấn đề này :xmaslaugh:),
Với tập tin Bạn gửi OT có lẽ phải dành nhiều thời gian hơn để nghiên cứu, hiện hôm OT bắt đầu đi làm trở lại nên có thể thông tin sau ạ.
Với OT có lẽ từ những ví dụ đơn giản nhất thậm trí trong cuộc sống thực tế hàng ngày có lẽ OT mới hiểu hiểu đc chút ít.
 
Upvote 0
Tôi dùng VB6/VBA theo kiểu cỗ lỗ nên chưa bao giờ thử khai báo dictionary/collection, đến lúc xài C# thì mới có cơ hội trải nghiệm. Tuy nhiên nếu tinh ý thì chúng ta có thể phát hiện là VBA cung cấp rất nhiều các dictionary/collection dựng sẵn. Chẳng hạn tập hợp Sheets (hay sheet gì đó) có thể truy cập từng phần tử bằng tên (kiểu như dictionary). Tương tự trên Form ta cũng có tập hợp controls, trong đối tượng Recordset cũng có tập hợp Fields (dùng tên field truy cập y chang dictionary)... Các collection/dictionary có sẵn này chắc kể cả ngày chắc chả hết --=0

Kinh nghiệm để khám phá ra các collection hay dictionary là chú ý tới dạng số nhiều hoặc có thêm thuộc tính count, item... Dựa theo cách dùng của Microsoft thì chúng ta sẽ tự "nội suy" ra cách dùng cho riêng ta sao cho phù hợp thôi.

Ưu điểm khi xài collection là giúp code ngắn hơn và gần gũi với tư duy ngôn ngữ con người hơn chẳng hạn "for each... next" hiểu là "với mỗi phần tử... làm cái gì đó.". Còn với dictionary là một phiên bản đặc biệt của collection thì bạn cứ xem tình huống nào cần dùng tới key thì xài. Cứ học tập các collection/dictionary có sẵn mà chúng ta vẫn dùng chán chê hằng ngày rồi tìm cách ứng dụng cho trường hợp của bản thân.
 
Lần chỉnh sửa cuối:
Upvote 0
Tôi thấy trên này ai đó hay sử dụng từ : thuật toán bảng băm đó .... thử mò ứng dụng xem sao ???
tôi toàn nghe nói cho vui à ... còn trên GPE này chưa thấy ai dùng nó ... mà tôi cũng ko có biết gì luôn
Nhưng tôi lại mới thấy trên Delphi tây nó viết ... mà nói thì tôi cũng ko biết nói từ đâu và như thế nào cho đúng
....
====> Nên cũng ko muốn nói và ko bao giờ nói cả :D:D:D
 
Upvote 0
Nhiều người hay lấy Collection và Dictionary để so sánh tốc độ chung chung là sai. Chúng ta chỉ so sánh khi làm một yêu cầu cụ thể. Và với yêu cầu cụ thể thì sẽ thấy rõ vai trò của từng cái. Hai đối tượng này có mục đích sử dụng khác nhau, tấc nhiên nó vẫn có thể dùng chung cho một mục đích nào đó. Bạn nên đọc tài liệu mô tả cấu trúc các thành phần của Collection và Dictionary.
 
Upvote 0
Xin chào các 'Đại ca' , cảm ơn các 'Đại ca' đã ghé thăm 'trại' của 'tiểu muội' và truyền đạt }}}}} :yahoo:, nhưng thực sự là 'tiểu muội' chưa đủ nội công để tiếp thu. (@$%@
Phiền các 'Đại ca' múa vài đường cơ bản của Collection và Dictionary được không ạ?
Bài đã được tự động gộp:

Nếu có Méc-sơ-đéc (đọc theo mới là mợt-sí-đì), còn ai muốn đi Ki-a hôn?
Vả lại, tốc độ còn tùy thuộc vào cách sử dụng và dữ liệu.
Collection là: Ki-a
còn Dictionary: Méc-sơ-đéc
Như vậy phải không Bác, nghĩa là cứ Méc-sơ-đéc mà đi Bác nhỉ }}}}}
 
Lần chỉnh sửa cuối:
Upvote 0
Với dữ liệu ở bài 1 thì tôi kiểm tra bằng For... Next còn nhanh hơn là Collection hay Dictionary. Vậy chắc cứ dùng vòng lặp là hiệu quả nhất :rolleyes:
Thớt thử ngẫm xem vì sao For... Next lại nhanh hơn, có thể ngộ ra điều gì đó.
Mã:
Sub ForNext()
Dim TT As Double
TT = Timer
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long, k As Long
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If KeyExists(Result, sKey, j, k) Then
                Result(k, 4) = Result(k, 4) + ArrData(i, 3)
            Else
                j = j + 1
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            End If
        End If
    Next i
    If j > 0 Then
        .Range("M2").Resize(100, 4).ClearContents
        .Range("M2").Resize(j, 4) = Result
        .Range("Q7") = Timer - TT
    End If
End With
End Sub
Private Function KeyExists(Result, sKey, j, k) As Boolean
For k = 1 To j
    If Result(k, 2) = sKey Then
        KeyExists = True
        Exit For
    End If
Next
End Function
 
Upvote 0
Xin chào các 'Đại ca' , cảm ơn các 'Đại ca' đã ghé thăm 'trại' của 'tiểu muội' và truyền đạt }}}}} :yahoo:, nhưng thực sự là 'tiểu muội' chưa đủ nội công để tiếp thu. (@$%@
Phiền các 'Đại ca' múa vài đường cơ bản của Collection và Dictionary được không ạ?
Bài đã được tự động gộp:


Collection là: Ki-a
còn Dictionary: Méc-sơ-đéc
Như vậy phải không Bác, nghĩa là cứ Méc-sơ-đéc mà đi Bác nhỉ }}}}}
Không phải là vậy đâu nha, thằng Collection nó chạy chậm với dữ liệu lớn, ngược lại nó chạy rất nhanh, còn Dictionary thì nó vẫn có thể nói "giữ phong độ" từ dữ liệu nhiều đến dữ liệu ít.
Nếu lọc duy nhất ngoài 2 em trên ta cũng có thể dùng ComboBox để thực hiện, cũng rất hiệu quả đó nha.
 
Upvote 0
Xin lỗi tất cả các mọi người bài 1 khi nãy OT đính kèm nhập tin 'SortedList' ạ.. OT đã cập nhật lại :wallbash:
 
Upvote 0
Với dữ liệu ở bài 1 thì tôi kiểm tra bằng For... Next còn nhanh hơn là Collection hay Dictionary. Vậy chắc cứ dùng vòng lặp là hiệu quả nhất :rolleyes:
Thớt thử ngẫm xem vì sao For... Next lại nhanh hơn, có thể ngộ ra điều gì đó.
Mã:
Sub ForNext()
Dim TT As Double
TT = Timer
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long, k As Long
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If KeyExists(Result, sKey, j, k) Then
                Result(k, 4) = Result(k, 4) + ArrData(i, 3)
            Else
                j = j + 1
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            End If
        End If
    Next i
    If j > 0 Then
        .Range("M2").Resize(100, 4).ClearContents
        .Range("M2").Resize(j, 4) = Result
        .Range("Q7") = Timer - TT
    End If
End With
End Sub
Private Function KeyExists(Result, sKey, j, k) As Boolean
For k = 1 To j
    If Result(k, 2) = sKey Then
        KeyExists = True
        Exit For
    End If
Next
End Function

Xin chào Anh @huuthang_bd, cảm ơn anh đã quan tâm & chỉ dẫn cụ thể hơn cho OT ạ:
Trong khả năng hiểu biết của OT thấy được 'ForNext' nhanh hơn Collection & Dictionary là vì ForNext chỉ chạy trong khoảng:
Mã:
For k = 1 To j
Nếu gặp key trùng nhau sẽ thoát khỏi vòng lặp:
Mã:
...
        If Result(k, 2) = sKey Then
            KeyExists = True
            Exit For
...
Trong khi Collection & Dictionary vẫn phải thực hiện các thao tác, kiểm tra key trong phạm vi:
For i = 1 To lRow

ủa nhưng mà có khác gì đâu nhỉ vì với Collection & Dictionary cũng kiểm tra trùng (có bao nhiêu key thì cũng tương tự For k = 1 To j như ForNext chỉ xet trong phạm vi đã gán key vào danh sách) :

với Collection:
Mã:
...
If KeyExists(myCol, sKey) = False Then
...
Mã:
'// Kiem tra su ton tai cua mot key trong Collection
Public Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function
với Dictionary :
Mã:
...
If Not Dic.Exists(sKey) Then
...

Hic, có lẽ OT cần nhiều thời gian để suy ngẫm ạ..
 
Upvote 0
Xin chào Anh @huuthang_bd, cảm ơn anh đã quan tâm & chỉ dẫn cụ thể hơn cho OT ạ:
Trong khả năng hiểu biết của OT thấy được 'ForNext' nhanh hơn Collection & Dictionary là vì ForNext chỉ chạy trong khoảng:
Mã:
For k = 1 To j
Nếu gặp key trùng nhau sẽ thoát khỏi vòng lặp:
Mã:
...
        If Result(k, 2) = sKey Then
            KeyExists = True
            Exit For
...
Trong khi Collection & Dictionary vẫn phải thực hiện các thao tác, kiểm tra key trong phạm vi:
For i = 1 To lRow

ủa nhưng mà có khác gì đâu nhỉ vì với Collection & Dictionary cũng kiểm tra trùng (có bao nhiêu key thì cũng tương tự For k = 1 To j như ForNext chỉ xet trong phạm vi đã gán key vào danh sách) :

với Collection:
Mã:
...
If KeyExists(myCol, sKey) = False Then
...
Mã:
'// Kiem tra su ton tai cua mot key trong Collection
Public Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function
với Dictionary :
Mã:
...
If Not Dic.Exists(sKey) Then
...

Hic, có lẽ OT cần nhiều thời gian để suy ngẫm ạ..
Thằng For ... Next nó lặp đi lặp lại từ đầu dữ liệu đến cuối dữ liệu để dò tìm "key" trùng, còn những thằng kia dường như nó cũng dò tìm nhưng dò tìm dữ liệu đã được add kiểu Find vậy đó nên nó "phát hiện" key trùng rất nhanh.
 
Upvote 0
Thằng For ... Next nó lặp đi lặp lại từ đầu dữ liệu đến cuối dữ liệu để dò tìm "key" trùng, còn những thằng kia dường như nó cũng dò tìm nhưng dò tìm dữ liệu đã được add kiểu Find vậy đó nên nó "phát hiện" key trùng rất nhanh.
Xin chào anh Nghĩa đẹp trai,
nghĩa là nếu chỉ cần xác định Key trùng hay không cứ 'ForNext' trong 'mảng':
Mã:
Private Function KeyExists(Result, sKey, j, k) As Boolean
    For k = 1 To j
        If Result(k, 2) = sKey Then
            KeyExists = True
            Exit For
        End If
    Next k
End Function
thì lúc nào cũng nhanh hơn là Collection,Dictionary phải không phải ạ?
Thưc tế OT đã sử dụng ForNext tại bài viết:
Mã:
Public Function aTimKiem(rFind As Range, sTim As String, c As Integer) As String
    Dim aData() As Variant, r As Long
    Const KXD As String = "Khong xac dinh"
    aData = rFind.Value2
    For r = 1 To UBound(aData, 1)
       If sTim = aData(r, 1) Then
            aTimKiem = aData(r, c)
            Exit For
       End If
    Next r
    If aTimKiem = Empty Then
        aTimKiem = KXD
    End If
End Function
Nhưng thực tế kết quả vẫn thua xa 'dictionary' so với vài viết của Bác @batman1 :
Mã:
    Set tenviettat = CreateObject("Scripting.dictionary")
    For r = 1 To UBound(FindPC_data, 1)
        skey = FindPC_data(r, 1)
        If Not tenviettat.exists(skey) Then tenviettat.Add skey, FindPC_data(r, 3)
    Next r
 
Lần chỉnh sửa cuối:
Upvote 0
Trong các bài viết trên đây thì câu phát biểu ở bài 9 của anh @Nguyễn Duy Tuân là đúng hơn cả:
"Nhiều người hay lấy Collection và Dictionary để so sánh tốc độ chung chung là sai. Chúng ta chỉ so sánh khi làm một yêu cầu cụ thể. Và với yêu cầu cụ thể thì sẽ thấy rõ vai trò của từng cái."
Tôi chỉ nói kinh nghiệm bản thân:
- Khi dữ liệu 1 triệu dòng, keys 10.000 cái, thì Dict và Collection tương đương, nhanh chậm hơn vài phần trăm giây
- Khi dữ liệu 10 ngàn dòng,, keys 9 ngàn, Dict rất rất chậm thậm chí chậm hơn thí dụ trên, Collection nhanh hơn 1 tẹo.
Cho nên đừng tuyên bố cái nào nhanh hơn cái nào.
 
Lần chỉnh sửa cuối:
Upvote 0
Xin chào anh Nghĩa đẹp trai,
nghĩa là nếu chỉ cần xác định Key trùng hay không cứ 'ForNext' trong 'mảng':
Mã:
Private Function KeyExists(Result, sKey, j, k) As Boolean
    For k = 1 To j
        If Result(k, 2) = sKey Then
            KeyExists = True
            Exit For
        End If
    Next k
End Function
thì lúc nào cũng nhanh hơn là Collection,Dictionary phải không phải ạ?
Ẹc ... ẹc ... với dữ liệu vài chục dòng thì sử dụng For ... Next cho nó đơn giản, chứ vài trăm vài ngàn dòng có mà chết!

Bài dưới đây tôi hướng dẫn bạn sử dụng ComboBox thật tiện lợi nè:

Mã:
Sub TestLocDuyNhat()
    Dim arrData
    Dim cbxTemp As MSForms.ComboBox
    Dim e As Long, n As Long, r As Long, u As Long
    Set cbxTemp = UserForm1.ComboBox1
    cbxTemp.Clear
    Sheet1.Columns("F:G").ClearContents
    e = Sheet1.Range("A" & Rows.Count).End(xlUp).Row
    arrData = Sheet1.Range("A1:B" & e).Value
    u = UBound(arrData)
    For r = 1 To u
        cbxTemp.Text = arrData(r, 1)
        If Not cbxTemp.MatchFound Then
            cbxTemp.AddItem arrData(r, 1), n
            cbxTemp.List(n, 1) = arrData(r, 2)
            n = n + 1
        Else
            cbxTemp.List(cbxTemp.ListIndex, 1) = cbxTemp.List(cbxTemp.ListIndex, 1) & " + " & arrData(r, 2)
        End If
    Next
    Sheet1.Range("F1:G" & cbxTemp.ListCount).Value = cbxTemp.List
End Sub
 

File đính kèm

Upvote 0
Upvote 0
Tôi chỉ nói kinh nghiệm bản thân:
- Khi dữ liệu 1 triệu dòng, keys 10.000 cái, thì Dict nhanh hơn, Collection chậm hơn
- Khi dữ liệu 10 ngàn dòng,, keys 9 ngàn, Dict rất rất chậm thậm chí chậm hơn thí dụ trên, Collection nhanh hơn 1 tẹo.
... với dữ liệu vài chục dòng thì sử dụng For ... Next cho nó đơn giản, chứ vài trăm vài ngàn dòng có mà chết!
Chốt lại là theo kinh nghiệm của chú Mỹ & anh Nghĩa thì OT thấy dù dữ liệu ít hay nhiều thì cứ nên sử dụng Dictionary cho ổn định vì dữ liệu ít thì khỏi bàn về tốc độ còn dữ liệu nhiều thì cứ Dictionary mà dùng ạ?
----
Vấn đề là trong phạm vi bài toán yêu cầu chỉ sử dụng Collection & Dictionary không dược phép sử dụng cái khác (như For...next...)
- Trường hợp nào bắt buộc phải dùng Dictionary mà không thể dùng Collection.
- Trường hợp nào bắt buộc phải dùng Collection mà không thể dùng Dictionary.
=> Thì chưa có ví dụ cụ thể ạ... nên OT cũng không thấy được về mục đích sử dụng cũng giống như bài toán phân biệt giữa ByVal & ByRef vậy.
 
Upvote 0
Chốt lại là theo kinh nghiệm của chú Mỹ & anh Nghĩa thì OT thấy dù dữ liệu ít hay nhiều thì cứ nên sử dụng Dictionary cho ổn định vì dữ liệu ít thì khỏi bàn về tốc độ còn dữ liệu nhiều thì cứ Dictionary mà dùng ạ?
----
Vấn đề là trong phạm vi bài toán yêu cầu chỉ sử dụng Collection & Dictionary không dược phép sử dụng cái khác (như For...next...)
- Trường hợp nào bắt buộc phải dùng Dictionary mà không thể dùng Collection.
- Trường hợp nào bắt buộc phải dùng Collection mà không thể dùng Dictionary.
=> Thì chưa có ví dụ cụ thể ạ... nên OT cũng không thấy được về mục đích sử dụng cũng giống như bài toán phân biệt giữa ByVal & ByRef vậy.
Thằng nào mà chả dùng vòng lặp For em? Chẳng qua "cơ cấu" thằng nào nhanh hơn thôi.
 
Upvote 0
Thay vì hỏi, thay vì làm theo kinh nghiệm của người khác thì mình tự thử nghiệm 4 cái gạch đầu dòng ở bài #5 ấy, để tự mình có kinh nghiệm của chính mình. Lúc đó hoàn toàn tự tin nêu ra kinh nghiệm của chính mình.
Và đảm bảo rằng, sau khi thử nghiệm xong 4 cái mục đó sẽ biết cái nào nên dùng vào trường hợp nào? Cũng tới lúc tìm hiểu cái mới, không nên cứ bám theo cái đã cũ.
 
Upvote 0
Cái này là anh sử dụng 'Form' khi chạy code OT không thấy hiện hiện cái Form là sao anh Nghĩa nhỉ? Hay là xử lý 'ngầm gì đó qua Form' thì tốc độ nhanh hơn vậy anh?
Form vẫn hoạt động, nhưng nó không được Show ra thôi em. Nó nhanh hơn For ... Next mà không dùng công cụ nào, bởi nó có thuộc tính Match Found nên rất nhanh.
 
Upvote 0
Thay vì hỏi, thay vì làm theo kinh nghiệm của người khác thì mình tự thử nghiệm 4 cái gạch đầu dòng ở bài #5 ấy, để tự mình có kinh nghiệm của chính mình. Lúc đó hoàn toàn tự tin nêu ra kinh nghiệm của chính mình.
Và đảm bảo rằng, sau khi thử nghiệm xong 4 cái mục đó sẽ biết cái nào nên dùng vào trường hợp nào? Cũng tới lúc tìm hiểu cái mới, không nên cứ bám theo cái đã cũ.
Cảm ơn Bạn nhiều @befaint
Phiền Bạn có thể chỉ dẫn cụ thể cho OT biết cách làm thử nghiệm và kiểm tra vấn đề này được không @befaint , có video ví dụ kèm theo thì là tốt nhất ạ.
- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
 
Upvote 0
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
Trong file ở bài đó làm rồi còn gì.

- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;

Const key = "key_xyz" '---> Đây là 1 key
Const num = 2000000
Dim i as long
For i = 1 to num
'kiem tra key khong co trong object '(*)
'add key vào object
object.add key, "" '---> add nhiều lần 1 key, thực ra là add có 1 lần, chỉ thử nghiệm cái dòng trên (*) thôi.
Next i.

Mình cứ đọc ---- thật ---- chậm thôi.
 
Upvote 0
Xin chào anh Nghĩa đẹp trai,
nghĩa là nếu chỉ cần xác định Key trùng hay không cứ 'ForNext' trong 'mảng':
Mã:
Private Function KeyExists(Result, sKey, j, k) As Boolean
    For k = 1 To j
        If Result(k, 2) = sKey Then
            KeyExists = True
            Exit For
        End If
    Next k
End Function
thì lúc nào cũng nhanh hơn là Collection,Dictionary phải không phải ạ?
huuthang_bd đã nói rõ là code viết cho bài #1, tức trường hợp cụ thể. Tập tin của bạn có 100009 dòng dữ liệu nhưng chỉ có (tôi không kiểm tra mà chỉ nhìn kết quả mà bạn nhập tay) 6 Mã khác nhau (Mã nhiều vô kể nhưng trùng cực nhiều, tức số Mã duy nhất là rất ít). Bạn hãy thử sửa dữ liệu sao cho có khoảng 50 000 Mã duy nhất, hoặc tất cả 100 009 Mã đều khác nhau từng đôi một rôi kiểm tra lại xem có đúng là luôn có For ... Next nhanh hơn hay không.

Muốn so sánh collection và dictionary thì dễ thôi.
1. So sánh về chức năng.
Bạn có biết collection và dictionary có những thuộc tính và phương thức nào không? Dĩ nhiên bạn đọc nhiều bài lý thuyết và bạn đã biết. Vậy thì cứ so sánh từng phương thức và từng thuộc tính thôi. Cả 2 có phương thức ADD không? Nếu có thì có cùng dễ dùng không? Có thuộc tính nào mà collection có nhưng dictionary không có, hoặc ngược lại không. Cái đó có là ưu điểm lớn không? Vd. dictionary có thuộc tính KEYS, ITEMS. Collection có không? Nếu không có thì KEYS, ITEMS có là điểm mạnh đáng mơ ước hay không.
Cứ so sánh từng phương thức, thuộc tính như thế.

2. So sánh về tốc độ?
Nghĩ ra vài bài toán, vài thể loại. Với mỗi bài thì chọn dữ liệu đa dạng. Tức lúc thì dữ liệu ít, lúc thì dữ liệu nhiều, cực nhiều. Lúc thì dữ kiệu cực nhiều nhưng số key duy nhất ít, lúc thì số key duy nhất nhiều nhiều, lúc thì tất cả các key là duy nhất.
 
Upvote 0
Chốt lại là theo kinh nghiệm của chú Mỹ ...
Tôi viết nhầm bài trên: sửa và bổ sung như sau:
- Khi dữ liệu 1 triệu dòng, keys 10.000 cái, thì Dict và Collection tương đương, nhanh chậm hơn vài phần trăm giây
- Khi dữ liệu 10 ngàn dòng,, keys 9 ngàn, Dict rất rất chậm thậm chí chậm hơn thí dụ trên, Collection nhanh hơn 1 tẹo. Nên dùng thứ khác như là HashTable
- Với dữ liệu vừa phải (50 ngàn dòng, khá ít keys), Collection nhanh hơn gấp đôi (chỉ cho việc add key, không tính phần code xử lý dữ liệu)
PHP:
Sub ExtractByCollection()

t = Timer
   Dim sArrID()
    Dim ColDM As Collection
    Dim EndR As Long
With Sheet20
    EndR = .Cells(65536, 1).End(xlUp).Row
    sArrID = .Range("G4:G" & EndR).Value2
End With
    Set ColDM = New Collection
For i = 1 To UBound(sArrID, 1)
    If Not KeyExists(ColDM, sArrID(i, 1)) Then
        k = k + 1
        ColDM.Add Item:=k, Key:=sArrID(i, 1)
    End If
Next
MsgBox Timer - t '0.125'
End Sub
/////
Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function
////
Sub ExtractByDictionary()
t = Timer
   Dim sArrID()
    Dim DictDM
    Dim EndR As Long
With Sheet20
    EndR = .Cells(65536, 1).End(xlUp).Row
    sArrID = .Range("G4:G" & EndR).Value2
End With
    Set DictDM = CreateObject("Scripting.Dictionary")
For i = 1 To UBound(sArrID, 1)
    If Not DictDM.Exists(sArrID(i, 1)) Then
        k = k + 1
        DictDM.Add sArrID(i, 1), k
    End If
Next
MsgBox Timer - t '0.325'
End Sub
File đính kèm chứa 50 ngàn dòng dữ liệu, 12 keys, Dict = 0.325 giây, Collect = 0.125 giây
Chạy ra báo cáo cũng nhanh hơn (sheet THNXT)
Khuyến mãi ảnh cháu ngoại mùng 4 tết

1613648313348.png
 

File đính kèm

Lần chỉnh sửa cuối:
Upvote 0
...
- Khi dữ liệu 1 triệu dòng, keys 10.000 cái, thì Dict và Collection tương đương, nhanh chậm hơn vài phần trăm giây
- Khi dữ liệu 10 ngàn dòng,, keys 9 ngàn, Dict rất rất chậm thậm chí chậm hơn thí dụ trên, Collection nhanh hơn 1 tẹo.
Cho nên đừng tuyên bố cái nào nhanh hơn cái nào.
Liệt kê của bạn còn thiếu tính chất của keys nữa.

Tại mọi người đọc bài #11, chỉ nghe đến "nhanh/chậm" là tối mắt hết rồi.
Nếu chịu khó mở mắt ra nhìn cho kỹ ngay đầu, người viết có nói:
"Với dữ liệu ở bài #1..."

Dữ liệu ấy có hơn 100 ngàn dòng, nhưng chỉ có 6 trị keys, mỗi trị key chỉ là chuỗi 5 ký tự.
Hàm tìm chỉ phải chạy 6 dòng trong mảng dò. Trung bình là 3 lượt. Và so sánh 5 ký tự cũng dễ bẹt.
Với đít sần, mỗi lần thử thì hàm băm phải băm 5 ký tự ấy ra, dùng trị băm đưa vào bảng dò. Nếu tôi không lầm thì đít sần trong thư viện script dùng cấu trúc b-tree để làm mục lục bảng băm. Chỉ có 6 nodes thì chưa chắc b-tree đã hiệu quả hơn mảng.
Túm lại, phân tích ra như sau:
1. với chỉ 5 ký tự thì so sánh thẳng nhanh hơn thảy vào cối mà băm.
2. với chỉ 6 phần tử thì mảng đi cái ọt, xong trước khi b-tree nó đọc được cái gốc (root) của nó, chưa chắc đã đến cái lá nào.

Chú: vì số keys rất ít, và keys rất ngắn cho nên tôi làm cái pivot table cũng chạy cái ọt. Thử 100 ngàn dòng 50 ngàn keys, 50 ký tự xem pivot có nổi không?

Pót xong mới thấy bác kia viết bài #27, phân tích đại khái cũng như tôi.
 
Upvote 0
huuthang_bd đã nói rõ là code viết cho bài #1, tức trường hợp cụ thể. Tập tin của bạn có 100009 dòng dữ liệu nhưng chỉ có (tôi không kiểm tra mà chỉ nhìn kết quả mà bạn nhập tay) 6 Mã khác nhau (Mã nhiều vô kể nhưng trùng cực nhiều, tức số Mã duy nhất là rất ít). Bạn hãy thử sửa dữ liệu sao cho có khoảng 50 000 Mã duy nhất, hoặc tất cả 100 009 Mã đều khác nhau từng đôi một rôi kiểm tra lại xem có đúng là luôn có For ... Next nhanh hơn hay không.

Muốn so sánh collection và dictionary thì dễ thôi.
1. So sánh về chức năng.
Bạn có biết collection và dictionary có những thuộc tính và phương thức nào không? Dĩ nhiên bạn đọc nhiều bài lý thuyết và bạn đã biết. Vậy thì cứ so sánh từng phương thức và từng thuộc tính thôi. Cả 2 có phương thức ADD không? Nếu có thì có cùng dễ dùng không? Có thuộc tính nào mà collection có nhưng dictionary không có, hoặc ngược lại không. Cái đó có là ưu điểm lớn không? Vd. dictionary có thuộc tính KEYS, ITEMS. Collection có không? Nếu không có thì KEYS, ITEMS có là điểm mạnh đáng mơ ước hay không.
Cứ so sánh từng phương thức, thuộc tính như thế.

2. So sánh về tốc độ?
Nghĩ ra vài bài toán, vài thể loại. Với mỗi bài thì chọn dữ liệu đa dạng. Tức lúc thì dữ liệu ít, lúc thì dữ liệu nhiều, cực nhiều. Lúc thì dữ kiệu cực nhiều nhưng số key duy nhất ít, lúc thì số key duy nhất nhiều nhiều, lúc thì tất cả các key là duy nhất.
Con chào Bác, cảm ơn Bác đã chỉ dẫn ạ.
Dạ đúng mới đầu suy nghĩ của con chỉ muốn tìm hiểu rõ về chức năng ạ, trong trường hợp nào dùng được Dic mà không thể dùng được collection ấy ạ và ngược lại bởi vì qua bài viết con đưa ở bài 1 con thấy collection có phần nhanh hơn nên con muốn hỏi thêm...
Sau nhiều bài viết thì con cũng đã hiểu sơ sơ chỉ là một chút thôi ạ vì chưa ngồi test cụ thể được.
Có lẽ tạm thời con xin phép chỉ theo dõi để các Bác và những người có kiến thức chuyên sâu thảo luận thêm ạ,vì bắt đầu trở lại với công việc hàng ngày và tối về bọn trẻ ăn với lại học online nên con cũng bận không như mấy hôm nghỉ tết ạ.
Sau khi nghiên cứu mổ sẻ có chỗ nào không hiểu con lại hỏi ở đây ạ.
 
Upvote 0
...
File đính kèm chứa 50 ngàn dòng dữ liệu, 12 keys, Dict = 0.325 giây, Collect = 0.125 giây
Code của bạn dùng đít sần ở dạng kết nối trễ.
Đã thử kết nối sớm chưa?

Tôi nhớ mang máng đọc ở đâu trong mớ tài liệu của MS về Office Automation thì kết nối trễ sẽ gọi hàm theo kiểu gián tiếp, và sẽ chậm gấp bội lần trực tiếp.
 
Upvote 0
Code của bạn dùng đít sần ở dạng kết nối trễ.
Đã thử kết nối sớm chưa?

Tôi nhớ mang máng đọc ở đâu trong mớ tài liệu của MS về Office Automation thì kết nối trễ sẽ gọi hàm theo kiểu gián tiếp, và sẽ chậm gấp bội lần trực tiếp.
Khai báo sớm, thời gian còn khoảng 1/5 so với khai báo trễ, với file ở bài 28, code Add đơn thuần, và nhanh hơn Collect :p :p :p. Cả code báo cáo cũng trở nên nhanh hơn Collection.
 
Lần chỉnh sửa cuối:
Upvote 0
Tôi viết nhầm bài trên: sửa và bổ sung như sau:
- Khi dữ liệu 1 triệu dòng, keys 10.000 cái, thì Dict và Collection tương đương, nhanh chậm hơn vài phần trăm giây
- Khi dữ liệu 10 ngàn dòng,, keys 9 ngàn, Dict rất rất chậm thậm chí chậm hơn thí dụ trên, Collection nhanh hơn 1 tẹo. Nên dùng thứ khác như là HashTable
- Với dữ liệu vừa phải (50 ngàn dòng, khá ít keys), Collection nhanh hơn gấp đôi (chỉ cho việc add key, không tính phần code xử lý dữ liệu)
PHP:
Sub ExtractByCollection()

t = Timer
   Dim sArrID()
    Dim ColDM As Collection
    Dim EndR As Long
With Sheet20
    EndR = .Cells(65536, 1).End(xlUp).Row
    sArrID = .Range("G4:G" & EndR).Value2
End With
    Set ColDM = New Collection
For i = 1 To UBound(sArrID, 1)
    If Not KeyExists(ColDM, sArrID(i, 1)) Then
        k = k + 1
        ColDM.Add Item:=k, Key:=sArrID(i, 1)
    End If
Next
MsgBox Timer - t '0.125'
End Sub
/////
Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function
////
Sub ExtractByDictionary()
t = Timer
   Dim sArrID()
    Dim DictDM
    Dim EndR As Long
With Sheet20
    EndR = .Cells(65536, 1).End(xlUp).Row
    sArrID = .Range("G4:G" & EndR).Value2
End With
    Set DictDM = CreateObject("Scripting.Dictionary")
For i = 1 To UBound(sArrID, 1)
    If Not DictDM.Exists(sArrID(i, 1)) Then
        k = k + 1
        DictDM.Add sArrID(i, 1), k
    End If
Next
MsgBox Timer - t '0.325'
End Sub
File đính kèm chứa 50 ngàn dòng dữ liệu, 12 keys, Dict = 0.325 giây, Collect = 0.125 giây
Chạy ra báo cáo cũng nhanh hơn (sheet THNXT)
Khuyến mãi ảnh cháu ngoại mùng 4 tết

View attachment 254272

Các bé lúc nào cũng dễ thương & đáng yêu tự nhiên, có lẽ do sự trong sáng tạo nên Chú Mỹ nhỉ.
Con test thử đoạn sau cũng thấy tốc độ chênh lệch giữa Collection & Dic gần gấp đôi:
Mã:
Option Explicit

Dim T As Double, sKey As String , i As Long, k As Long
Const r As Long = 666666

Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function

Sub Test_Collection()
    T = Timer
    Dim Coll As Collection
    Set Coll = New Collection
    k = 0
    For i = r To 1 Step -2
        sKey = i / 2 '& i
        If Not KeyExists(Coll, sKey) Then
            k = k + 1
            Coll.Add Item:=k, Key:=sKey
        End If
    Next i
    Debug.Print "sKey: " & k & "---" & "Collection time: " & Timer - T
    'sKey: 333333---Collection time: 2.7265625
End Sub

Sub Test_Dictionary()
    T = Timer
    Dim Dic
    Set Dic = CreateObject("Scripting.Dictionary")
    k = 0
    For i = r To 1 Step -2
        sKey = i / 2 '& i
        If Not Dic.Exists(sKey) Then
            k = k + 1
            Dic.Add sKey, k
        End If
    Next i
    Debug.Print "sKey: " & k & "---" & "Dictionary time: " & Timer - T
    'sKey: 333333---Dictionary time: 4.8203125
End Sub
Và con đang tìm xem test với trường hợp nào Dic lợi thế hơn...
 
Upvote 0
Dic tuy nhanh hơn trước nhưng vẫn thua xa col Chú ạ:
View attachment 254276
Tin hay không tùy bạn, nhưng mình dám khẳng định rằng cách bạn đang học code sai trầm trọng. Đó là nguyên nhân tại sao bạn học code bấy lâu nay mà chưa đâu vào đâu. Nếu là tôi thì tôi không dại gì đua tốc độ, càng không nên so sánh khập khiễng giữa Collection và Dictionary. So sánh kiểu đi tìm câu trả lời cho câu hỏi "Tiền và Tình, cái nào quan trọng hơn?" Có thể bây giờ bạn chưa tin, thời gian sau này có thể bạn sẽ phải tin. Vài lời chân tình, bạn hãy suy gẫm nhé.
 
Upvote 0
Tin hay không tùy bạn, nhưng mình dám khẳng định rằng cách bạn đang học code sai trầm trọng. Đó là nguyên nhân tại sao bạn học code bấy lâu nay mà chưa đâu vào đâu. Nếu là tôi thì tôi không dại gì đua tốc độ, càng không nên so sánh khập khiễng giữa Collection và Dictionary. So sánh kiểu đi tìm câu trả lời cho câu hỏi "Tiền và Tình, cái nào quan trọng hơn?" Có thể bây giờ bạn chưa tin, thời gian sau này có thể bạn sẽ phải tin. Vài lời chân tình, bạn hãy suy gẫm nhé.
Dạ Anh, OT vẫn đang loay hoay tìm hiểu từng vấn đề mà anh, giờ mà dính tìm hiểu về 'tình' nữa thì chìm không còn sức lực để sống nữa Anh }}}}}
Vừa rồi là tốc độ,còn giờ là đang so sánh tính năng ạ.
OT đang thấy phần bôi vàng Dic chiếm ưu thế hơn Col ạ:

1613668655190.png
 

File đính kèm

Upvote 0
huuthang_bd đã nói rõ là code viết cho bài #1, tức trường hợp cụ thể. Tập tin của bạn có 100009 dòng dữ liệu nhưng chỉ có (tôi không kiểm tra mà chỉ nhìn kết quả mà bạn nhập tay) 6 Mã khác nhau (Mã nhiều vô kể nhưng trùng cực nhiều, tức số Mã duy nhất là rất ít). Bạn hãy thử sửa dữ liệu sao cho có khoảng 50 000 Mã duy nhất, hoặc tất cả 100 009 Mã đều khác nhau từng đôi một rôi kiểm tra lại xem có đúng là luôn có For ... Next nhanh hơn hay không.

Muốn so sánh collection và dictionary thì dễ thôi.
1. So sánh về chức năng.
Bạn có biết collection và dictionary có những thuộc tính và phương thức nào không? Dĩ nhiên bạn đọc nhiều bài lý thuyết và bạn đã biết. Vậy thì cứ so sánh từng phương thức và từng thuộc tính thôi. Cả 2 có phương thức ADD không? Nếu có thì có cùng dễ dùng không? Có thuộc tính nào mà collection có nhưng dictionary không có, hoặc ngược lại không. Cái đó có là ưu điểm lớn không? Vd. dictionary có thuộc tính KEYS, ITEMS. Collection có không? Nếu không có thì KEYS, ITEMS có là điểm mạnh đáng mơ ước hay không.
Cứ so sánh từng phương thức, thuộc tính như thế.

2. So sánh về tốc độ?
Nghĩ ra vài bài toán, vài thể loại. Với mỗi bài thì chọn dữ liệu đa dạng. Tức lúc thì dữ liệu ít, lúc thì dữ liệu nhiều, cực nhiều. Lúc thì dữ kiệu cực nhiều nhưng số key duy nhất ít, lúc thì số key duy nhất nhiều nhiều, lúc thì tất cả các key là duy nhất.
Con chào Bác,
Sau một hồi test , có lẽ con đã hiểu thêm một chút xíu nữa Bác ạ, cụ thể con cảm nhận như sau:
- Về chức năng Dic hơn hẳn Col (con nêu ở bài 38).
- Về tốc độ (con mô tổ toàn bộ đoạn code phía dưới):
Key càng nhiều thì Col càng nhanh Dic càng chậm mà ForNext thì thôi siêu chậm ạ.
Key ít thì Col sẽ chậm hơn Dic một chút và ForNext sẽ nhanh ạ.

Mã:
Option Explicit

Private Const r As Long = 666666
Dim T As Double, sKey As String, i As Long, j As Long, k As Long

Private Function KeyExists_ForNext(Result, sKey, j, k) As Boolean
For k = 1 To j
    If Result(k, 1) = sKey Then
        KeyExists_ForNext = True
        Exit For
    End If
Next k
End Function

Sub ForNext()
    T = Timer
    Const n As Long = 666666
    'Const n As Long =65000
    Dim Result(1 To n, 1 To 1)
    k = 0: j = 0
    For i = n To 1 Step -1
        'sKey = i / 2
        sKey = i Mod 3
        If Not KeyExists_ForNext(Result, sKey, j, k) Then
            j = j + 1
            Result(j, 1) = sKey
        End If
    Next i
    Debug.Print "sKey: " & j & " --- " & "ForNext time: " & Timer - T
    'Neu: sKey = i / 2 va n  = 65000
    'sKey: 32500 --- ForNext time: 42.98193359375
    
    'Neu: sKey = i Mod 3 va n  = 666666 (=r)
    'sKey: 3 --- ForNext time: 0.09814453125
End Sub


Private Function KeyExists(myCol As Collection, ByVal keyCheck As String) As Boolean
    KeyExists = False
    On Error GoTo EndFunction
    myCol.Item keyCheck
    KeyExists = True
EndFunction:
End Function

Sub Test_Collection()
    T = Timer
    Dim Coll As Collection
    Set Coll = New Collection
    k = 0
    For i = r To 1 Step -1
        sKey = i / 2
        'sKey = i Mod 3
        If Not KeyExists(Coll, sKey) Then
            k = k + 1
            Coll.Add Item:=k, Key:=sKey
        End If
    Next i
    Debug.Print "sKey: " & k & " --- " & "Collection time: " & Timer - T
    'Neu: sKey = i / 2
    'sKey: 666666 --- Collection time: 5.291015625
    
    'Neu: sKey = i Mod 3
    'sKey: 3 --- Collection time: 0.23583984375
End Sub

Sub Test_Dictionary()
    T = Timer
    Dim Dic As New Scripting.Dictionary
    k = 0
    For i = r To 1 Step -1
        'sKey = i / 2
        sKey = i Mod 3
        If Not Dic.Exists(sKey) Then
            k = k + 1
            Dic.Add sKey, k
        End If
    Next i
    Debug.Print "sKey: " & k & " --- " & "Dictionary time: " & Timer - T
    'Neu: sKey = i / 2
    'sKey: 666666 --- Dictionary time: 18.06591796875
    
    'Neu: sKey = i Mod 3
    'sKey: 3 --- Dictionary time: 0.06396484375
End Sub

Con mới hiểu chừng đó, có gì Bác chỉ dẫn thêm ạ.
Xin cảm ơn tất cả mọi người đã chỉ dẫn cho OT ạ, hic OT ngủ để mai còn đi làm đi làm ạ @@!
 
Upvote 0
Key càng nhiều thì Col càng nhanh Dic càng chậm mà ForNext thì thôi siêu chậm ạ.
Cũng tùy theo bạn cho là thế nào là nhiều. Về lý thuyết thì có thể có vd. 1 hoặc 2 triệu Mã khác nhau, nhưng trong bài toán thực tế mà hàng ngày bạn phải giải quyết thì số các Mã khác nhau nó thuộc cỡ nào? Bạn không phải là những ông giáo sư ngồi trên bàn nhậu bàn về lý thuyết. Bạn là nhà thực hành, giải quyết các bài toán trong thực tế. Bài toán với 1 triệu Mã khác nhau thường gặp hơn hay bài toán với 1000 hoặc 100 000 Mã khác nhau hay gặp hơn trong cuộc sống? 100 000 Mã KHÁC NHAU là con số NHIỀU chưa? Nếu đó là con số lớn, thực tế hơn, thì trong 2 code test bạn sửa thành sKey = i Mod 100000 rồi test xem có còn Key càng nhiều thì Col càng nhanh Dic càng chậm không nhé.

Theo tôi bạn nên tạm gác chuyện tốc độ sang một bên. Nếu tôi hiểu thì bạn chưa hiểu hết collection, dictionary. Vậy thì trước hết hãy hiểu chúng, sử dụng chúng thuần thục. Còn khi gặp bài toán cụ thể mà bạn thấy dictionary chậm thì lúc đó tìm cách khác cũng chả bao giờ muộn.

1. Collection:
- key không thể là số (không quan trọng lắm), không thể là OBJECT (nhược điểm lớn)
- Chỉ có Remove, không thể xóa hết các item, key (chỉ còn nước hủy đối tượng và tạo lại)
- không có phương thức Exists, Items, Keys
- không có thuộc tính Key
- không dùng được trong các tập tin VBS (dùng VB Script)
- với key không phân biệt hoa thường. Tức nếu đã có key là "Hic hic" thì không thể thêm key mới là "hic hic".

2. Dictionary:
- key có thể là chuỗi, số và OBJECT (vd. là đít sần khác)
- có Remove và RemoveAll
- có phương thức Exists, Items, Keys
- có thuộc tính Key cho phép thay đổi giá trị key đang tồn tại.
- dùng được trong các tập tin VBS (dùng VB Script)
- có thuộc tính CompareMode nên có thể chủ động phân biệt hoa thường hay không.

Chính vì những hạn chế của collection nên theo tôi nếu có thể code đơn giản cho bài toán nào đấy bằg collection thì cũng code được đơn giản bằng đít sần, nhưng ngược lại không đúng. Có những bài mà có thể code đơn giản dùng đít sần nhưng không làm đơn giản được bằng collection.
 
Upvote 0
Dic tuy nhanh hơn trước nhưng vẫn thua xa col Chú ạ:
Lại so sánh khập khiễng: Code bài 28 là 50 ngàn dữ liệu, 12 keys, code test của mi là 66 ngàn với 33 ngàn keys, tỷ lệ quá khác biệt
Ngoài ra phải đọc lại bài trên của bác @batman1 về phương pháp test và tính năng, và trên nữa của bác @VetMini về kiểu của keys: Nếu key là String và dài thì thế nào, thậm chí có khi phải dùng thứ khác như HashTable, ...
 
Lần chỉnh sửa cuối:
Upvote 0
Ngoài ra phải đọc lại bài trên của bác @batman1 về phương pháp test và tính năng, và trên nữa của bác @VetMini về kiểu của keys: Nếu key là String và dài thì thế nào, thậm chí có khi phải dùng thứ khác như HashTable, ...
Tôi nghĩ là độ dài key cũng không đáng ngại. Cái quan trọng là có tất cả bao nhiêu dữ liệu (key) và trong đó số key duy nhất là bao nhiêu.

Như trong bài #5 ta có:
Mã:
Private Const maxCount = 1048500
Private Const prefixKey = "ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
...
For i = 1 To maxCount
    sKey = prefixKey & i
Tức hơn 1 triệu key và cũng là hơn 1 triệu key duy nhất, có độ dài từ 28 (i = 1..9) tới 34 ký tự. Bài toán với hơn 1 triệu key duy nhất tôi thấy có vẻ ít gặp trong cuộc sống văn phòng. Nếu ta sửa thành sKey = prefixKey & (i Mod 100000), tức hơn 1 triệu key nhưng số key duy nhất là 100 000, và vẫn độ dài ấy thì có lẽ đít thon ít mỡ sẽ cho collection biết thế nào là lễ độ.

Mọi người thử xem sao nhé.
 
Upvote 0
@Hoàng Nhật Phương :
Quan trọng là thuật toán, và thói quen sử dụng cái nào thì dùng cái đó
Và tùy thuộc vào trường hợp cụ thể, không phải ngẫu nhiên mà Họ lập ra và tồn tại cả 2 thứ này Dictionary , Collection...
Nên câu hỏi mãi cũng là câu hỏi tiếp tục...

Nhưng tóm lại cả 2 chúng chỉ là công cụ mà thôi, sử dụng công cụ cho trường hợp nào, cách nào mới cần, hơn là so sánh cái nào hơn cái nào.
Với các bài toán ở diễn đàn này thì toàn nhỏ và khá nhỏ nên dùng công cụ nào cũng không khác nhau nhiều, nên quen gì dùng đó thôi, chưa kể có khi code kiểu dùng 1 lần (dành cho người hỏi) rồi bỏ, hoặc cả tháng cả năm sau mới dùng lại, ... thì chi phí thời gian băn khoăn chọn công cụ nào chỉ làm lãng phí cũng như vô ích.
 
Upvote 0
...
Theo tôi bạn nên tạm gác chuyện tốc độ sang một bên. Nếu tôi hiểu thì bạn chưa hiểu hết collection, dictionary. Vậy thì trước hết hãy hiểu chúng, sử dụng chúng thuần thục. Còn khi gặp bài toán cụ thể mà bạn thấy dictionary chậm thì lúc đó tìm cách khác cũng chả bao giờ muộn.

1. Collection:
- key không thể là số (không quan trọng lắm), không thể là OBJECT (nhược điểm lớn)
- Chỉ có Remove, không thể xóa hết các item, key (chỉ còn nước hủy đối tượng và tạo lại)
- không có phương thức Exists, Items, Keys
- không có thuộc tính Key
- không dùng được trong các tập tin VBS (dùng VB Script)
- với key không phân biệt hoa thường. Tức nếu đã có key là "Hic hic" thì không thể thêm key mới là "hic hic".

2. Dictionary:
- key có thể là chuỗi, số và OBJECT (vd. là đít sần khác)
- có Remove và RemoveAll
- có phương thức Exists, Items, Keys
- có thuộc tính Key cho phép thay đổi giá trị key đang tồn tại.
- dùng được trong các tập tin VBS (dùng VB Script)
- có thuộc tính CompareMode nên có thể chủ động phân biệt hoa thường hay không.
...
Cảm ơn Bác Siwtom đã góp ý và chỉ dẫn chi tiết cho con ạ.
Dạ đúng rồi Bác trước hết con cũng nghĩ là nên làm vậy ạ.
------
Xin cảm ơn tất cả mọi người đã góp ý, sự thảo luận nhiều đúng là luôn mang lại những kiến thức hữu ích mặc dù khả năng tiếp thu của OT rất là kém.
Mặc dù chưa hiểu hết về ưu nhước điểm của Dic và Col nhưng qua đây OT cũng đã cảm thấy bản thân mình đã biết sử dụng các công cụ này, OT sẽ cố gắng sử dụng vào các bài toán của mình sắp tới để có thể có thêm kinh nghiệm ạ.
 
Upvote 0
Tôi nghĩ là độ dài key cũng không đáng ngại. Cái quan trọng là có tất cả bao nhiêu dữ liệu (key) và trong đó số key duy nhất là bao nhiêu.
Mọi người thử xem sao nhé.
Vâng anh, tôi cũng nghĩ như vậy nên tôi cũng nói là "xem thế nào", nghĩa là so sánh với cùng 1 số lượng key thì tốc độ cũng phải bị thay đổi theo chiều dài key
Thử theo anh bảo thì thấy với tỷ lệ key/ dữ liệu càng ít thì Dict càng nhanh, 50.000 keys thì Collect hít khói, 10.000 keys thì thậm chí không có khói để hít. Thế mới thấy cần phải test trên diện vừa rộng vừa sâu

1613704097923.png
 
Upvote 0
Ở đây ta nói "Đít Sần" là nói về cái công cụ COM của MS, nằm trong thư viện Script Runtime.

- Vì mục đích chính để hổ trợ Script cho nên nó bắt buộc phải bao những trường hợp cần thiết của Script.
- Vì mục đích chính là tạo một phép áp trực tiếp (map) từ một giá trị (key) sang giá trị khác (item), không hề nề hà kiểu của bên đầu vào lẫn đầu ra cho nên nó bắt buộc phải sử dụng những thuật toán rất phức tạp bên trong. Và những thuật toán này có thể mâu thuẫn nhau về hiệu quả, ví dụ A là thuật toán băm key dạng chuỗi, B là thuật toán băm key dạng số, để A hiệu quả hơn thì phải hy sinh hiệu quả của B; tác giả đít sần bắt buộc phải chọn "75% trường hợp người dùng sẽ dùng key chuỗi, vậy thì chọn ưu tiên A" (*1)

Chú ý vào điều kiện thứ hai kể trên, nó bắt buộc phải dựa trên môi trường làm việc chủ đich (điều kiện thứ nhất) mà cân nhắc các thuật toán bên trong. Nói cách khác, nếu dữ liệu của bạn nằm đúng trường hợp mà nó đã chọn làm tối ưu thì sẽ thấy nó chạy êm như ru.

Mặt khác:
Cờ loét sần ở đây là cấu trúc dữ liệu được cung cấp nội bộ, bên trong môi trường VBA. Và cái loét sần này làm đúng nhiệm vụ của nó: nơi lưu trữ.
- Nó sẽ lưu trữ dữ liệu theo đúng thứ tự thằng nào vào trước thì lấy số 1, thằng kế lấy số 2,... (*2)
- Nó sẽ cho phép bạn dùng một cái id (dạng chuỗi) để 'đánh dấu' từng phần tử.
sheets trong Excel là ví dụ điển hình của loét sần: mỗi sheet có số thứ tự và tên của nó (*3)
Vì môi trường đã chỉ định, và vì điều kiện sử dụng cũng rõ rệt, cho nên MS dễ dàng hơn khi chọn một vùng mượt/sweet spot (*4) cho loét sần.
Rất có thể điều kiện mà quý vị tét trên kia lọt vào vùng mượt của nó.

Ở chủ đề bài này (bài #1), thớt chỉ nói về "ứng dụng thường gặp trong GPE", tức là "lọc duy nhất". Và so sánh này nọ cũng là dựa trên 2 "tôn chỉ của GPE":
1. ứng dụng lọc duy nhất
2. tốc độ chạy
cộng một điều, tuy không phải là "tôn chỉ" nhưng rất thường gặp, coi như là "cố tật của GPE"
3. dữ liệu khủng và méo mó (rất ít khi chuẩn)

(*1) nếu quý vị theo dõi cái đít sần này thường xuyên sẽ nhớ mấy năm trước có vụ tét ra nó làm việc với key chuỗi nhanh hơn key số.

(*2) tuy bạn thường thấy đít sần cũng cho ra thứ tự nhập như vậy, nhưng MS không hề bảo đảm việc này cho đít sần, dựa vào đó mà viết code thì chết có ngày.

(*3) theo hướng đối tượng, cái lớp loét sần mà sheet sử dụng chỉ thừa kế từ lớp loét sần căn bản thôi, chính nó còn còn có nhiều giao diện khác.

(*4) tôi đã từng đề cập vụ "vùng mượt" này nhiều lần. Các nhà viết code luôn luôn phải dùng thống kê để đoán vùng data mà người dùng hay gặp nhất, và viết code ưu tiên cho loại dữ liệu này.
Vì dân GPE hay sử dụng dữ liệu kiểu mà MS đoán không nổi cho nên rất dễ lâm vào tình trạng "nếu muốn nhanh thì phải tự tìm lấy cái thích hợp hơn mà dùng"
 
Lần chỉnh sửa cuối:
Upvote 0
Xin chào các Bạn,
Đầu xuân chúc mọi người luôn mạnh khỏe & bình an.
----
Như tiêu đề OT đã nêu, OT có đọc bài viết của Bạn Collection @befaint nhưng có lẽ do kiến thức còn hạn hẹp nên chưa thể hiểu hết về sự khác biệt giữa Dictionary & Collection,
Ví dụ trong 2 đoạn code dưới đây sử dụng Dictionary & Collection cho cùng một công việc:
Mã:
Option Explicit

Sub CollectionFilter()
Dim TT As Double
TT = Timer
Dim myCol As Collection
Set myCol = New Collection
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If KeyExists(myCol, sKey) = False Then
                j = j + 1
                myCol.Add j, sKey
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            Else
                Result(myCol.Item(sKey), 4) = Result(myCol.Item(sKey), 4) + ArrData(i, 3)
             End If
        End If
    Next i
    If j > 0 Then
        .Range("M2").Resize(100, 4).ClearContents
        .Range("M2").Resize(j, 4) = Result
        .Range("Q7") = Timer - TT
    End If
End With


End Sub


Sub DictionaryFilter()
Dim TT As Double
TT = Timer

Dim Dic As Object
Dim i As Long, lRow As Long, ArrData(), Result(), sKey As String, j As Long
Set Dic = CreateObject("Scripting.Dictionary")
With Sheet1
    lRow = .Range("B" & Rows.Count).End(xlUp).Row
    ArrData = .Range("B2:D" & lRow).Value2
    lRow = UBound(ArrData, 1)
    ReDim Result(1 To lRow, 1 To 4)
    For i = 1 To lRow
        sKey = ArrData(i, 1)
        If sKey <> "" Then
            If Not Dic.Exists(sKey) Then
                j = j + 1
                Dic.Add sKey, j
                Result(j, 1) = j
                Result(j, 2) = sKey
                Result(j, 3) = ArrData(i, 2)
                Result(j, 4) = ArrData(i, 3)
            Else
                Result(Dic.Item(sKey), 4) = Result(Dic.Item(sKey), 4) + ArrData(i, 3)
            End If
        End If
    Next i
    If j > 0 Then
        .Range("H2").Resize(100, 4).ClearContents
        .Range("H2").Resize(j, 4) = Result
        .Range("L7") = Timer - TT
    End If
End With

End Sub
Trên máy tính của OT có vẻ như Collection nhanh hơn Dictionary :
View attachment 254243

Nhờ các bạn chỉ dẫn cho OT hiểu rõ thêm trong trường hợp nào thì dùng cái nào sẽ tối ưu hơn?
Tại sao Collection nhanh hơn Dictionary mà không thấy mọi người sử dụng Collection mà thường sử dụng Dictionary hơn hay do thói quen ạ?
Nếu so sánh về tốc độ với ADO thì ADO sẽ không thể so bì kịp với bài toán này. Tuy nhiên được cái nó dễ chỉnh sửa và bảo trì code.

1613718861883.png
 
Upvote 0
Nếu so sánh về tốc độ với ADO thì ADO sẽ không thể so bì kịp với bài toán này. Tuy nhiên được cái nó dễ chỉnh sửa và bảo trì code.

View attachment 254308
Anh đã khơi khơi ra rồi thì ít ra cũng phải show code ra cho cho OT chứ Anh (mặc dù chủ đề không liên quan gì đến ADO ạ),
với khả năng của OT là cứ ví dụ & kèm code thực tế thì mới có vừa ý Anh ạ, :p
 
Upvote 0
Ẹc ... ẹc ... với dữ liệu vài chục dòng thì sử dụng For ... Next cho nó đơn giản, chứ vài trăm vài ngàn dòng có mà chết!

Bài dưới đây tôi hướng dẫn bạn sử dụng ComboBox thật tiện lợi nè:

Mã:
Sub TestLocDuyNhat()
    Dim arrData
    Dim cbxTemp As MSForms.ComboBox
    Dim e As Long, n As Long, r As Long, u As Long
    Set cbxTemp = UserForm1.ComboBox1
    cbxTemp.Clear
    Sheet1.Columns("F:G").ClearContents
    e = Sheet1.Range("A" & Rows.Count).End(xlUp).Row
    arrData = Sheet1.Range("A1:B" & e).Value
    u = UBound(arrData)
    For r = 1 To u
        cbxTemp.Text = arrData(r, 1)
        If Not cbxTemp.MatchFound Then
            cbxTemp.AddItem arrData(r, 1), n
            cbxTemp.List(n, 1) = arrData(r, 2)
            n = n + 1
        Else
            cbxTemp.List(cbxTemp.ListIndex, 1) = cbxTemp.List(cbxTemp.ListIndex, 1) & " + " & arrData(r, 2)
        End If
    Next
    Sheet1.Range("F1:G" & cbxTemp.ListCount).Value = cbxTemp.List
End Sub
Code này chạy nhanh nè, thử 5000 key tôi cảm thấy chạy rất ngọt ngào, khi nhìn code thấy .listindex tôi không nghĩ code có thể chạy mượt như vậy, và khi năng lên 10000 key thì tôi cảm thấy nó không mượt mà như trước nữa. Code này có điểm cộng lớn, nếu hiểu bản chất mà trau truốt thêm tôi nghĩ sẽ rất tiềm năng.
 
Upvote 0
Anh đã khơi khơi ra rồi thì ít ra cũng phải show code ra cho cho OT chứ Anh (mặc dù chủ đề không liên quan gì đến ADO ạ),
với khả năng của OT là cứ ví dụ & kèm code thực tế thì mới có vừa ý Anh ạ, :p
Code group bình thường thôi em, tuy nhiên nó không giống với kết quả của em ở chỗ là nó đã sắp xếp. Còn code của em thì nó vẫn giữ nguyên. Nếu như code của em thêm vào cái sắp xếp nữa thì nó sẽ khớp với dùng ADO của anh.
 
Upvote 0
Upvote 0
Code group bình thường thôi em, tuy nhiên nó không giống với kết quả của em ở chỗ là nó đã sắp xếp. Còn code của em thì nó vẫn giữ nguyên. Nếu như code của em thêm vào cái sắp xếp nữa thì nó sẽ khớp với dùng ADO của anh.
là sao Anh chắc anh đang nhầm với đề tài bên kia rồi
hú hú @!>><
 
Upvote 0
Dạ Anh, sau khi anh Tuân cũng nói về group OT mới nghĩ chắc OT nhầm ạ.
Code của anh như sau:
Mã:
Sub Test()
    Dim t As Double
    t = Timer
    With CreateObject("ADODB.Recordset")
        .Open " Select [Code],MIN([Date]),sum(Quantity) from [A1:D] Group By [Code]", "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & ThisWorkbook.FullName & ";Extended Properties=Excel 12.0"
        Sheet1.Range("I12").CopyFromRecordset .DataSource
        Sheet1.Range("L12") = Timer - t
    End With
End Sub
 
Upvote 0
Code của anh như sau:
Mã:
Sub Test()
    Dim t As Double
    t = Timer
    With CreateObject("ADODB.Recordset")
        .Open " Select [Code],MIN([Date]),sum(Quantity) from [A1:D] Group By [Code]", "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & ThisWorkbook.FullName & ";Extended Properties=Excel 12.0"
        Sheet1.Range("I12").CopyFromRecordset .DataSource
        Sheet1.Range("L12") = Timer - t
    End With
End Sub
Cảm ơn Anh đã chỉ thêm một cách nữa, OT test rồi code không báo lỗi.
Còn mọi cái OT bàn gì nữa ạ..ở đây xung quanh toàn là 'Cây cổ thụ' với 'Núi cao' nên OT chỉ đứng ngồi ngắm và chiêm ngưỡng thưởng thức thôi ạ. :xmaslaugh:
 
Upvote 0
Ở đây ta nói "Đít Sần" là nói về cái công cụ COM
Dic dùng bảng băm. Nếu vậy sự tương đồng của các key cũng sẽ anh hưởng tới dic đúng không bác. Ví dụ cặp key( ac, ab) ( hai cái này giống nhau chũ a)sẽ khác tryowngf hợp cặp key( ac, df)
 
Upvote 0
Tôi nghĩ là độ dài key cũng không đáng ngại. Cái quan trọng là có tất cả bao nhiêu dữ liệu (key) và trong đó số key duy nhất là bao nhiêu.

Như trong bài #5 ta có:
Mã:
Private Const maxCount = 1048500
Private Const prefixKey = "ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
...
For i = 1 To maxCount
    sKey = prefixKey & i
Tức hơn 1 triệu key và cũng là hơn 1 triệu key duy nhất, có độ dài từ 28 (i = 1..9) tới 34 ký tự. Bài toán với hơn 1 triệu key duy nhất tôi thấy có vẻ ít gặp trong cuộc sống văn phòng. Nếu ta sửa thành sKey = prefixKey & (i Mod 100000), tức hơn 1 triệu key nhưng số key duy nhất là 100 000, và vẫn độ dài ấy thì có lẽ đít thon ít mỡ sẽ cho collection biết thế nào là lễ độ.

Mọi người thử xem sao nhé.
Khả năng của ai có thể viết Hàm Tự tạo được như mô tả của bài này mà Nhanh hơn Dic của Bill thì viết ... Còn ko viết được thì cứ Dic của Bill lôi ra mà xài cho nhanh
 
Upvote 0
Upvote 0
Upvote 0
Tôi xin chịu ...
... tìm ai đó trên GPE này mà mấy năm nay lâu lâu lại nói tới thuật ngữ Bảng Băm ấy ..
Hic, cảm ơn Bạn đã cho OT biết.. nếu Bạn mà chịu thì OT đến mùa nào,mà ai vậy cứ nghe thấy Băm chém là OT thấy hãi quá, Ot chỉ đọc nhiều bài liên quan đến chủ đề của OT thôi ạ.. nhưng dù 'Cây cổ thủ' nào chăng nữa thì tạm thời OT cũng xin phép dừng vấn đề này ở đây ạ kẻo lại sang chủ đề khác ạ (nếu ai đó mà bạn nói tới có thể chỉ cho OT vấn đề này để OT làm được thì xin xui lòng chuyển qua chủ đề bên đó ạ).
 
Upvote 0
Băm với biếc. Quên đi.
Thuật toán dựng các cấu trúc hổ trợ cách search index table phức tạp bỏ bố. Cái giản dị nhất trong bọn là search cây nhị phân, số người có khả năng hiểu trên diễn đàn này đếm được trên đầu ngón tay.
 
Upvote 0
Code này chạy nhanh nè, thử 5000 key tôi cảm thấy chạy rất ngọt ngào, khi nhìn code thấy .listindex tôi không nghĩ code có thể chạy mượt như vậy, và khi năng lên 10000 key thì tôi cảm thấy nó không mượt mà như trước nữa. Code này có điểm cộng lớn, nếu hiểu bản chất mà trau truốt thêm tôi nghĩ sẽ rất tiềm năng.
Trong cái bài đó mình khuyến mãi thêm cái cột thứ 2 là cộng dồn (có thể là chuỗi, cũng có thể là số) các giá trị ở cột 2, nếu không, chỉ đơn giản là lọc duy nhất 1 cột thì có lẽ nó cũng không phải chậm lắm đâu. Và dùng combobox cũng có thể remove 1 item hoặc tất cả.
 
Upvote 0
.. Nếu ta sửa thành sKey = prefixKey & (i Mod 100000), tức hơn 1 triệu key nhưng số key duy nhất là 100 000, và vẫn độ dài ấy thì có lẽ đít thon ít mỡ sẽ cho collection biết thế nào là lễ độ.
Dạ, Bác thực sự là mới năm ngoái con thường làm việc với dữ liệu trong Database nên dữ liệu nhiều vô kể thậm trí có lúc copy ra Excel để sử dụng VBA nhưng Excel không đủ sức chứa nó vì thế mà con đã tìm đến ngôn ngữ SQL để xử lý,dữ liệu sau khi đổ xuống Excel gần như gọi là báo cáo đã được rút gọn đi rất rất Bác ạ, và có lẽ số key duy nhất cũng không thể vượt con số 100,000 (với dữ liệu con hay dùng có lẽ lớn nhất vẫn là báo thẻ kho từ thời điểm đến thời điểm).
(với dữ liệu lớn này chỉ có dùng phần mềm là nhanh nhưng phần mềm thì lại có những hạn chế không theo ý muốn mà theo ýthì lại phải mất phí chính vì vậy mà nếu có thể sử dụng được các câu lệnh truy vấn được thì con thấy vẫn là chủ động nhất ạ.)
Có cái khác 'ngon' hơn thế nữa là đằng khác.
Chuyện thử nghiệm phải phân định các trường hợp của dữ liệu đầu vào để thử nghiệm:
- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
- Add nhiều keys có tỉ lệ trùng 30-50-90%... <--- trường hợp hỗn hợp.
- Còn trường hợp kiểu dữ liệu của key: Number, String. Cái này Dictionary còn mệt nữa.

Việc Add key là công việc rất nặng nề, sau một thời gian thử nghiệm thấy Dictionary rất đuối.
Với 'Hashtable' OT có biết đến qua những lần Bạn sử dụng nhưng OT cũng chưa đọc kỹ và để ý đến nó, mới so sánh công cụ này với Dic và Col trong tập tin bạn gửi thì lại hơn hẳn.
Hình như cái này đòi hỏi phải cài thêm gì đó (OT nhớ không rõ) vì có lần lâu lắm rồi khi chạy code bị lỗi OT phải cài gì đó hay là sửa sang Dic thì phải.
Cảm ơn Bạn đã cho OT thêm cách này để so sánh, nhìn cách dùng nó cũng tương tự với cách dùng Dic lắm (tự nhiên nổi máu tham muốn như muốn mở rộng chủ đề để quá hihi chết mất). -\\/.
 
Upvote 0
Dạ, Bác thực sự là mới năm ngoái con thường làm việc với dữ liệu trong Database nên dữ liệu nhiều vô kể thậm trí có lúc copy ra Excel để sử dụng VBA nhưng Excel không đủ sức chứa nó vì thế mà con đã tìm đến ngôn ngữ SQL để xử lý,dữ liệu sau khi đổ xuống Excel gần như gọi là báo cáo đã được rút gọn đi rất rất Bác ạ, và có lẽ số key duy nhất cũng không thể vượt con số 100,000 (với dữ liệu con hay dùng có lẽ lớn nhất vẫn là báo thẻ kho từ thời điểm đến thời điểm).
(với dữ liệu lớn này chỉ có dùng phần mềm là nhanh nhưng phần mềm thì lại có những hạn chế không theo ý muốn mà theo ýthì lại phải mất phí chính vì vậy mà nếu có thể sử dụng được các câu lệnh truy vấn được thì con thấy vẫn là chủ động nhất ạ.)
Bởi bạn chú ý đến tốc độ mà ví dụ kết luận là đít sần đuối nên tôi có lưu ý thôi.

Trong bài #5 có hơn 1 triệu key và đó cũng là hơn 1 triệu key DUY NHẤT. Kết luận là đít sần "tê" đến mức không lê nổi. Tôi chỉ muốn lưu ý là cũng dữ liệu khủng đó nhưng nếu lượng key DUY NHẤT khác thì tình hình lại khác. Và tôi muốn lưu ý nữa là bài toán nào sát thực tế hơn.
1. Trong công việc thực tế hàng ngày số lần bạn gặp hơn 1 triệu key DUY NHẤT là bao nhiêu lần?
2. Nếu số key DUY NHẤT là khoảng 100 000 thì bạn chỉ cần sửa như tôi hướng dẫn thì bạn cũng sẽ thấy là cũng với dữ liệu khủng 1 triệu key nhưng số key DUY NHẤT là 100 000 thì bây giờ đít sần lại phi như bay về đích. Bạn đã thử như tôi hướng dẫn chưa, kết quả thế nào? Bạn không cho biết cụ thể.

Do bạn cứ nghĩ là collection hoặc đít sần nhanh hơn nên mục đích của tôi chỉ là chỉ ra các trường hợp cụ thể, khi mà collection hoặc đít sần nhanh hơn. Tùy lượng dữ liệu, số key duy nhất, và mục đích cần tính gì mà chọn phương pháp, công cụ thôi bạn ạ. Bạn hãy học cách sử dụng mọi công cụ có trong xưởng, còn dùng cái nào thì tùy vào công việc cụ thể. Hôm nay cần đào cái rãnh nhỏ trong vườn thì dùng xẻng thôi. Ngày mai cần đào móng thì dùng máy đào máy xúc.
 
Upvote 0
(với dữ liệu lớn này chỉ có dùng phần mềm là nhanh nhưng phần mềm thì lại có những hạn chế không theo ý muốn mà theo ýthì lại phải mất phí chính vì vậy mà nếu có thể sử dụng được các câu lệnh truy vấn được thì con thấy vẫn là chủ động nhất ạ.)
Theo mình thấy có gì đó sai sai, mình không biết bạn làm bộ phận gì mà nghĩ sợ công ty mất phí....(có phải tiền bạn đâu nhỉ ??? Hay bạn muốn thể hiện để ...)
Nếu vậy bạn tự nhiên cứu đi, có thực mới giật được đạo chứ nhỉ
 
Upvote 0
Bởi bạn chú ý đến tốc độ mà ví dụ kết luận là đít sần đuối nên tôi có lưu ý thôi.

Trong bài #5 có hơn 1 triệu key và đó cũng là hơn 1 triệu key DUY NHẤT. Kết luận là đít sần "tê" đến mức không lê nổi. Tôi chỉ muốn lưu ý là cũng dữ liệu khủng đó nhưng nếu lượng key DUY NHẤT khác thì tình hình lại khác. Và tôi muốn lưu ý nữa là bài toán nào sát thực tế hơn.
1. Trong công việc thực tế hàng ngày số lần bạn gặp hơn 1 triệu key DUY NHẤT là bao nhiêu lần?
2. Nếu số key DUY NHẤT là khoảng 100 000 thì bạn chỉ cần sửa như tôi hướng dẫn thì bạn cũng sẽ thấy là cũng với dữ liệu khủng 1 triệu key nhưng số key DUY NHẤT là 100 000 thì bây giờ đít sần lại phi như bay về đích. Bạn đã thử như tôi hướng dẫn chưa, kết quả thế nào? Bạn không cho biết cụ thể.

Do bạn cứ nghĩ là collection hoặc đít sần nhanh hơn nên mục đích của tôi chỉ là chỉ ra các trường hợp cụ thể, khi mà collection hoặc đít sần nhanh hơn. Tùy lượng dữ liệu, số key duy nhất, và mục đích cần tính gì mà chọn phương pháp, công cụ thôi bạn ạ. Bạn hãy học cách sử dụng mọi công cụ có trong xưởng, còn dùng cái nào thì tùy vào công việc cụ thể. Hôm nay cần đào cái rãnh nhỏ trong vườn thì dùng xẻng thôi. Ngày mai cần đào móng thì dùng máy đào máy xúc.
Dạ vâng Bác, con cảm ơn Bác nhiều ạ.

Đọc lại bài 45, code chạy sẵn và so sánh sẵn
Trời ạ, tại Chú hôm nay hỏi con nhiều mà đi đường con quá cả lối về nhà một đoạn dài, giờ con mới về đến nhà đây. Hic
Bài đã được tự động gộp:

Theo mình thấy có gì đó sai sai, mình không biết bạn làm bộ phận gì mà nghĩ sợ công ty mất phí....(có phải tiền bạn đâu nhỉ ??? Hay bạn muốn thể hiện để ...)
Nếu vậy bạn tự nhiên cứu đi, có thực mới giật được đạo chứ nhỉ
Cảm ơn bạn đã quan tâm, thực ra OT chỉ làm nhân viên thống kê thôi nhưng do cả một quá trình hoạt động cải tiến của công ty với bản tính cứ đâu là bon chen nên nó đến giờ mọi việc nó trở nên như vậy đó thực ra chỉ cũng chỉ là đa mê công việc thôi.. vấn đề này cũng nhiều người hỏi OT trên GPE này rồi có thể bạn không để ý nên không biết thôi, vài lởi là vậy.
Công ty OT nghèo lắm bạn ạ, mua được phần mềm là một sự cố gắng rồi.
Chỉ là vài lời chia sẻ lại thôi mong bạn cũng đừng để ý thêm để ảnh hưởng đến vấn đề ngoài lề ạ.
 
Lần chỉnh sửa cuối:
Upvote 0
Dạ vâng Bác, con cảm ơn Bác nhiều ạ.


Trời ạ, tại Chú hôm nay hỏi con nhiều mà đi đường con quá cả lối về nhà một đoạn dài, giờ con mới về đến nhà đây. Hic
Bài đã được tự động gộp:


Cảm ơn bạn đã quan tâm, thực ra OT chỉ làm nhân viên thống kê thôi nhưng do cả một quá trình hoạt động cải tiến của công ty với bản tính cứ đâu là bon chen nên nó đến giờ mọi việc nó trở nên như vậy đó thực ra chỉ cũng chỉ là đa mê công việc thôi.. vấn đề này cũng nhiều người hỏi OT trên GPE này rồi có thể bạn không để ý nên không biết thôi, vài lởi là vậy.
Công ty OT nghèo lắm bạn ạ, mua được phần mềm là một sự cố gắng rồi.
Chỉ là vài lời chia sẻ lại thôi mong bạn cũng đừng để ý thêm để ảnh hưởng đến vấn đề ngoài lề ạ.
Hihi bởi vậy mình mới nói mình cảm thấy "sai sai". Theo ý kiến cá nhân của mình thì không phải tiền của mình thì mình sẽ cố gắng lấy quyền lợi về người lao động cao nhất có thể, nhất là những người có nhiệt huyết với công ty, mình xin lỗi làm lạc đề của chủ đề.
Mình xin stop tại đây
 
Upvote 0
Hihi bởi vậy mình mới nói mình cảm thấy "sai sai". Theo ý kiến cá nhân của mình thì không phải tiền của mình thì mình sẽ cố gắng lấy quyền lợi về người lao động cao nhất có thể, nhất là những người có nhiệt huyết với công ty, mình xin lỗi làm lạc đề của chủ đề.
Mình xin stop tại đây
Không sao Bạn, năm ngoái có thời điểm OT còn được anh @Hai Lúa Miền Tây teamviewer tại máy trong cơ quan để xử lý vấn đề liên quan đến SQL và xem Anh code và hướng dẫn mất hàng giờ đến giờ OT vẫn còn ấn tượng, và rất nhiều người OT còn mang ơn để OT có ngày hôm nay mà không có cơ hội để đáp lại .. hihi tâm trạng nên viết thêm một chút OT cũng dừng vấn đề riêng tư của OT ạ.
 
Upvote 0
(*2) tuy bạn thường thấy đít sần cũng cho ra thứ tự nhập như vậy, nhưng MS không hề bảo đảm việc này cho đít sần, dựa vào đó mà viết code thì chết có ngày.
Vậy cái dụ application.transpose(dic.keys) và application.transpose(dic.items) có đảm bảo luôn khớp nhau không bác?
 
Upvote 0
Trong chăn mới biết có nhóc gì. :)
Câu chuyện dữ liệu lớn và lớn, dùng Excel/ Google sheets giờ đây phổ biến rồi.
Xin chào @befaint
OT không thể đem dữ liệu thực cứ vậy mà gửi lên được Bạn (dữ liệu nhiều, không hẳn nói lên được việc kinh doanh phát triển lợi nhuận có). Bạn nói rất đúng trong chăn mới biết,đôi khi muốn hỏi hơn nữa nhưng OT không thể.. vì hỏi nữa OT sẽ phải xác nhận rất nhiều thậm trí phải qua cấp trên xác nhận,bản thân, công ty thậm trí khách hàng..mong bạn thông cảm, câu nói dữ liệu lớn mờ nhạt OT không muốn mọi người để ý vì trích dẫn chỉ riêng với Bác Siwtom (@batmnat1) thôi bởi cả một quá trình từ thơ dại đến lúc này của OT Bác ấy cũng đã dành thời gian không ít cho OT trên GPE này ...
 
Lần chỉnh sửa cuối:
Upvote 0
Vậy cái dụ application.transpose(dic.keys) và application.transpose(dic.items) có đảm bảo luôn khớp nhau không bác?
keys là một hàm trả về một mảng, items cũng vậy.
Trả lời theo đoán mò (không có tài liệu, dùng thống kê để đoán):
Người ta vẫn hay coi như chúng song song thì chắc là 2 cái mảng ấy nó đi cặp với nhau.
Nhưng vì không thấy MS nói gì về điều này, bảo đảm 100% thì chưa dám.
Nói cách khác, đánh cược hai ăn một thì tôi cược, nhưng 10 ăn một thì chờ tìm tài liệu hoặc kiếm được thằng bạn nào đó để hỏi.

Thử như vầy:
- lập một cái dic
- add, remove, đổi keys, đổi items nhiều lần
(nếu chỉ add thì chả có gì để tét, phai xoá đổi tùm lum nới hy vọng nó ảnh hưởng đến thứ tự)

chạy code:
For i = 0 To dic.Count - 1
If Dic.Items()(i) <> Dic(Dic.Keys()(i)) Then
Debug.Print "Broken at index = " & i
End If
Next i
 
Upvote 0
Tôi nghĩ là độ dài key cũng không đáng ngại. Cái quan trọng là có tất cả bao nhiêu dữ liệu (key) và trong đó số key duy nhất là bao nhiêu.

Như trong bài #5 ta có:
Mã:
Private Const maxCount = 1048500
Private Const prefixKey = "ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
...
For i = 1 To maxCount
    sKey = prefixKey & i
Tức hơn 1 triệu key và cũng là hơn 1 triệu key duy nhất, có độ dài từ 28 (i = 1..9) tới 34 ký tự. Bài toán với hơn 1 triệu key duy nhất tôi thấy có vẻ ít gặp trong cuộc sống văn phòng. Nếu ta sửa thành sKey = prefixKey & (i Mod 100000), tức hơn 1 triệu key nhưng số key duy nhất là 100 000, và vẫn độ dài ấy thì có lẽ đít thon ít mỡ sẽ cho collection biết thế nào là lễ độ.

Mọi người thử xem sao nhé.
Dạ Bác, nếu chỉ có danh mục mã hàng thôi thì số key duy nhất con làm việc không quá 10 000 , còn nếu liên quan mã và ngày tháng thì số lượng key duy nhất có lẽ cũng không vượt quá 100 000 ạ. Con test thử kết quả như sau Bác, thử chạy mấy lần thì trên máy của con Dic vẫn chậm hơn Col một chút Bác ạ (con đính kèm tập tin Bác xem ạ):
1613794410501.png
Ở chỗ môi trường con làm việc nếu dữ liệu lớn (ví dụ là 1triệu như thế này ) mà thời gian nhanh chậm không quá 30 giây thì là chuyện bình thường thôi ạ.
 

File đính kèm

Upvote 0
Vâng anh, tôi cũng nghĩ như vậy nên tôi cũng nói là "xem thế nào", nghĩa là so sánh với cùng 1 số lượng key thì tốc độ cũng phải bị thay đổi theo chiều dài key
Thử theo anh bảo thì thấy với tỷ lệ key/ dữ liệu càng ít thì Dict càng nhanh, 50.000 keys thì Collect hít khói, 10.000 keys thì thậm chí không có khói để hít. Thế mới thấy cần phải test trên diện vừa rộng vừa sâu

View attachment 254297
Theo như bảng này của Chú Mỹ thì với con nếu làm việc với dữ liệu thông thường trên Excel thì con thấy cột E là phù hợp nhất chọn Dic để thực hành là tốt nhất vừa nhiều chức năng vừa nhanh.
 
Upvote 0
Dạ Bác, nếu chỉ có danh mục mã hàng thôi thì số key duy nhất con làm việc không quá 10 000 , còn nếu liên quan mã và ngày tháng thì số lượng key duy nhất có lẽ cũng không vượt quá 100 000 ạ. Con test thử kết quả như sau Bác, thử chạy mấy lần thì trên máy của con Dic vẫn chậm hơn Col một chút Bác ạ (con đính kèm tập tin Bác xem ạ):
View attachment 254326
Ở chỗ môi trường con làm việc nếu dữ liệu lớn (ví dụ là 1triệu như thế này ) mà thời gian nhanh chậm không quá 30 giây thì là chuyện bình thường thôi ạ.
Bài 45 chẳng nói là càng ít càng giảm, 100.000 còn thua, đến 50.000 keys mới qua mặt mà

Theo như bảng này của Chú Mỹ thì với con nếu làm việc với dữ liệu thông thường trên Excel thì con thấy cột E là phù hợp nhất chọn Dic để thực hành là tốt nhất vừa nhiều chức năng vừa nhanh.
70.000 cũng qua mặt 1 bánh xe
 
Upvote 0
Bài 45 chẳng nói là càng ít càng giảm, 100.000 còn thua, đến 50.000 keys mới qua mặt mà
Bài đã được tự động gộp:


70.000 cũng qua mặt 1 bánh xe

Bài 45 chẳng nói là càng ít càng giảm, 100.000 còn thua, đến 50.000 keys mới qua mặt mà


70.000 cũng qua mặt 1 bánh xe
Sau khi test xong con mới đọc lại thấy bài của Chú, trong giờ làm thi thoảng con chỉ lướt lướt thôi, cảm ơn Chú Mỹ đã test thử và chỉ ra mấy trường hợp ạ.
Con đi ăn đã sau đó sẽ trả lời Chú Mỹ ở kênh bên kia ạ.:p
 
Upvote 0
Trong chăn mới biết có nhóc gì. :)
Câu chuyện dữ liệu lớn và lớn, dùng Excel/ Google sheets giờ đây phổ biến rồi.
Rất tiếc là công nghệ phát triển cấp số nhân nhưng việc phát triển trí tuệ của người dùng lại không "phổ biến" như bạn hy vọng.
Dữ liệu lớn nhưng khả năng tư duy người dùng không lớn theo.
Để bù đắp khả năng tư duy, đáng lẽ con người phải cố tâm học hỏi và làm việc hơn. Thay vì vậy, người ta lợi dụng công nghệ mạng xã hội để nhờ người khác học và làm giùm mình từ a đến z.
Cứ nghe những câu "làm nhiều thủ cong sợ sai", "làm thủ công chắc em chết mất", vân vân thì biết cái "phổ biến" bạn nói trên chỉ là lý tưởng.
 
Upvote 0
Rất tiếc là công nghệ phát triển cấp số nhân nhưng việc phát triển trí tuệ của người dùng lại không "phổ biến" như bạn hy vọng.
Dữ liệu lớn nhưng khả năng tư duy người dùng không lớn theo.
Để bù đắp khả năng tư duy, đáng lẽ con người phải cố tâm học hỏi và làm việc hơn. Thay vì vậy, người ta lợi dụng công nghệ mạng xã hội để nhờ người khác học và làm giùm mình từ a đến z.
Cứ nghe những câu "làm nhiều thủ cong sợ sai", "làm thủ công chắc em chết mất", vân vân thì biết cái "phổ biến" bạn nói trên chỉ là lý tưởng.
Vâng anh.
Cũng theo xu thế đó, giờ cũng là lúc phân hóa rõ rệt, một bên là những người chịu thay đổi, học hỏi, một bên là luôn có sẵn lý do để từ chối.
 
Upvote 0
theo dõi diết thấy chủ thớt khoãng 1 năm lại đây cũng chịu cày code ghê đấy chứ....
cũng ko đến nổi như người khác vác trỏng tre ra gốc cây sung ngồi hóng mát :D :D :D
 
Upvote 0
Dạ Bác, nếu chỉ có danh mục mã hàng thôi thì số key duy nhất con làm việc không quá 10 000 , còn nếu liên quan mã và ngày tháng thì số lượng key duy nhất có lẽ cũng không vượt quá 100 000 ạ. Con test thử kết quả như sau Bác, thử chạy mấy lần thì trên máy của con Dic vẫn chậm hơn Col một chút Bác ạ (con đính kèm tập tin Bác xem ạ):
View attachment 254326
Ở chỗ môi trường con làm việc nếu dữ liệu lớn (ví dụ là 1triệu như thế này ) mà thời gian nhanh chậm không quá 30 giây thì là chuyện bình thường thôi ạ.
Thế thì tùy system. Trên máy tôi Windows 10 64 bit 1.60 GHz RAM 4 GB + Excel 2013 32 bit thì kết quả như hình. Rõ ràng đít sần cho collection và hashtable biết thế nào là lễ độ.
Trong video đính kèm tôi kéo thanh trượt trong VBE chậm để mọi người kiểm tra code để tránh nghi ngờ là tôi sửa lại code.

tocdo.jpg


Máy bạn nhanh tới mức nào? Và phiên bản Excel? Phiên bán của tôi củ chuối là 2013 32 bit.
Ngoài ra với cỡ 100 000 key DUY NHẤT thì cả ở máy tôi và máy anh Mỹ hashtable phải lạy đít thon không mỡ bằng cụ mà ở máy bạn lại hơn đít thon một chút.
 
Lần chỉnh sửa cuối:
Upvote 0
Vậy thì có thể đúng có là rất có thể là như vậy rồi Bác ạ,
Con không nhớ rõ hay không nhưng hôm qua lúc vừa làm vừa thử code qua qua con có copy đoạn code này chạy thử thấy có chênh nhau giữa Dic & Col (Dic hơn Col như Bác đã đề cập) nhưng ko nhớ chính xác con số là bao nhiêu , hôm nay con thử lại thấy Dic lại chậm hơn một chút nên ngạc nhiên mới đầu con cũng định hỏi liệu máy móc ảnh hưởng gì đến tốc độ giữa cái kia không (giống như hiện trạng máy của Bác bây giờ đó ạ) nhưng phải kiểm tra lại code thật kỹ xem có làm đúng theo Bác chỉ dẫn hay không thậm trí khởi động lại máy tính nhưng kết quả vẫn như dữ liệu test con gửi chỉ là mỗi lần chạy số có thay đổi một chút (chênh lệch nhiều thì khoảng 1 giây giữa các lần chạy).
Giờ Bác nói con có nhớ là máy tính của con hôm nay có update cái gì đó sau đấy con bấm update rồi khởi động.
Cấu hình máy tính của con Windows 10 64 bit - hình như Ram8GB , Excel 2019 64bit, Bác ạ.
Nhưng dù gì đi nữa với ai muốn thử tìm hiểu nữa thì thử nhưng vẫn vấn đề con thấy sử dụng Dic là phù hợp cho nhu cầu của ạ, chỉ cần cố làm quen nhiều hơn cho nhớ ạ.
Bác giữ gìn sức khỏe ạ,con cảm ơn Bác.

theo dõi diết thấy chủ thớt khoãng 1 năm lại đây cũng chịu cày code ghê đấy chứ....
cũng ko đến nổi như người khác vác trỏng tre ra gốc cây sung ngồi hóng mát :D :D :D
Cảm ơn Bạn đã quan tâm,
Cũng giống như Bác Siwtom thông tin ở trên:
"Bạn hãy học cách sử dụng mọi công cụ có trong xưởng, còn dùng cái nào thì tùy vào công việc cụ thể. Hôm nay cần đào cái rãnh nhỏ trong vườn thì dùng xẻng thôi. Ngày mai cần đào móng thì dùng máy đào máy xúc"
Với môi trường của OT nếu công việc chỉ dùng cho bản thân mình thì OT có thể tìm hiểu các công cụ có sẵn tìm hiểu Google sheets, Pivot,Power query..
không phải máy tính nào cũng được cho phép kết nối mạng để sử dụng.
Và vấn đề lớn là vì các file dữ liệu thường có nhiều người sử dụng,người sau thường dùng theo những gì của người trước để lại (không mấy khi sửa đổi có thể vì không đủ kiến thức, hoặc là do qui định theo biểu mẫu..)
Nếu cứ mỗi người làm một kiểu không thống nhất thì sẽ rất là khó vì tiến độ công việc và độ chính xác là ưu tiên hàng đầu do vậy trong trường hợp một người mới khi thay công việc của người cũ có kinh nghiệm thì cũng phải làm được Bạn ạ.
Thường thì khi có động lực hoặc sự đam mê thì sẽ có sự nỗ nực..OT rất thích thú với hoạt động cải tiến,khi được cấp trên ghi nhận thì sẽ mang lại niềm tin và trao cho mình cảm hứng thêm. Hơn nữa không có ai có thể sống và giúp mình mãi như thế này được bản thân OT cũng ngại khi nhờ vả.
có điều là OT rất nhanh quên nếu không động đến là sẽ quên ngay ạ..
 
Lần chỉnh sửa cuối:
Upvote 0
Nếu tôi nhớ ko lầm thì trên 5 Năm trước trên GPE này họ cũng đã test thử các kiểu rồi ... cuối cùng cũng phải thừa nhận Dic là số 1
Tìm loạt bài trong nick vodoi gì đó ... tính xuất nhập tồn dữ liệu khủng gì đó ... những thành viên viết bài trong thớt này ngày đó cũng có tham gia đấy
Loại bài này ko mới vì ngày xưa trên này họ đã làm và đo tốc độ các kiểu rồi ............................ ===> tìm đi là thấy
 
Upvote 0
Cảm ơn Bạn,qua việc tìm hiểu và nhận được nhiều lời khuyên của mọi người nên OT không còn ý nghĩ muốn tìm hiểu hay bàn về tốc độ hơn kém nhau với đơn vị chục giây nữa và cảm nhận của OT đã cũng đã nêu ra ở bài 80 ạ.
 
Upvote 0
- Add nhiều keys không trùng lần nào <--- kiểm tra Add key vào object;
Trong file ở bài đó làm rồi còn gì.

- Add nhiều lần 1 key <--- thử nghiệm phần kiểm tra sự tồn tại key trong object;

Const key = "key_xyz" '---> Đây là 1 key
Const num = 2000000
Dim i as long
For i = 1 to num
'kiem tra key khong co trong object '(*)
'add key vào object
object.add key, "" '---> add nhiều lần 1 key, thực ra là add có 1 lần, chỉ thử nghiệm cái dòng trên (*) thôi.
Next i.

Mình cứ đọc ---- thật ---- chậm thôi.
Giờ mạnh mới tin là thuật toán Hash table tự tạo có thể nhanh hơn Dic đấy .... @befaint có tin không ???
không phải hash khai báo xài của bill nha
 
Upvote 0

Bài viết mới nhất

Back
Top Bottom