Cải thiện thời gian khởi động ứng dụng WPF nhận thức

Question

Tôi có ứng dụng trình xem cơ sở dữ liệu WPF: Đây là cửa sổ chính đơn giản có chứa điều khiển người dùng với lưới dữ liệu hiển thị dữ liệu được trích xuất từ ​​cơ sở dữ liệu SQLite.
Vấn đề là ứng dụng này mất 6 giây để bắt đầu cho đến khi có thể sử dụng được.

Tôi đã thử xây dựng điều khiển người dùng (và thực hiện tất cả tải dữ liệu) trong hàm dựng của cửa sổ chính:
Màn hình giật sẽ hiển thị 5s theo cách này, sau đó tiếp theo là 1s của cửa sổ chính trống cho đến khi ứng dụng sẵn sàng để được sử dụng.
Người dùng cho biết phải mất quá nhiều thời gian cho đến khi có điều gì đó (trực quan) xảy ra.

Sau đó, tôi đã chuyển chế độ điều khiển người dùng (và tải dữ liệu) vào trình xử lý sự kiện được tải của cửa sổ chính: Màn hình giật sẽ hiển thị 3 giây, sau đó là 3s của cửa sổ chính trống cho đến khi ứng dụng sẵn sàng.
Người dùng nói rằng nó "tốt hơn", nhưng không thích thực tế là một nửa cửa sổ chính đã hoàn thành được hiển thị ở trạng thái bị tắt quá lâu.

Có một số lời khuyên chung về thời gian tải ứng dụng hoặc có bất kỳ đề xuất nào khác về tình trạng này có thể được cải thiện không?
Tôi tin rằng lý tưởng cửa sổ chính sẽ được hiển thị nhanh nhất có thể, cùng với kính hoặc kính xoay một giờ cho đến khi dữ liệu được tải. Nhưng sau đó tôi không thể chỉ di chuyển việc tạo điều khiển người dùng thành một nhân viên nền vì điều này sẽ được thực hiện trên một chuỗi sai.

Có ai có bất kỳ đề xuất nào về vấn đề này không?

Chỉnh sửa:
Lưu ý rằng ngay bây giờ tôi vừa gán truy vấn LINQ-to-EF làm nguồn dữ liệu lưới.
Một cải tiến khả năng có thể để tải dữ liệu này vào một bảng dữ liệu ở chế độ nền và gán nó chỉ một lần nạp ...

Edit2: Tôi đang sử dụng .net 4 với System.Data.SQLite và EF4 để tải dữ liệu. Có ít nhất 4000 hàng và 30 cột.

Answer 1

Tải dữ liệu của bạn không đồng bộ. Trình bày một cái gì đó tốt đẹp trên GUI cho người dùng trong khi tải. Các mã sau đây có thể giúp bạn với điều này:

BackgroundWorker bgWorker = new BackgroundWorker() { WorkerReportsProgress=true}; 
bgWorker.DoWork += (s, e) => {  
    // Load here your file/s  
    // Use bgWorker.ReportProgress(); to report the current progress 
}; 
bgWorker.ProgressChanged+=(s,e)=>{  
    // Here you will be informed about progress and here it is save to change/show progress. 
    // You can access from here savely a ProgressBars or another control. 
}; 
bgWorker.RunWorkerCompleted += (s, e) => {  
// Here you will be informed if the job is done. 
// Use this event to unlock your gui 
}; 
bgWorker.RunWorkerAsync(); 

Ứng dụng không phải là nhanh hơn nhưng nó có vẻ là nhanh hơn nhiều vì giao diện là ngay lập tức nhìn thấy được và đáp ứng. Có lẽ bạn cũng có thể hiển thị cho người dùng một phần của dữ liệu được tải trong khi tải phần còn lại. Sử dụng số ProgressChanged -để thực hiện việc này.

Cập nhật

Tôi không chắc chắn nếu tôi hiểu vấn đề của bạn đúng. Nếu vấn đề của bạn không phải là dữ liệu thời gian cần được tải, thì có điều gì đó lạ trong ứng dụng của bạn. WPF là IMO rất nhanh. Việc tạo điều khiển không mất nhiều thời gian. Tôi hình dung nhiều danh sách lớn hơn khi bạn đề cập trong một vài phần nghìn giây.

Hãy thử tìm xem bạn có điều gì đó trong giao diện người dùng của bạn cản trở DataGrid để ảo hóa các mục. Có lẽ bạn có một proplem ở đó. Để phân tích các ứng dụng WPF, tôi có thể giới thiệu cho bạn WPF Profiling Tools.

Answer 2

Điều rõ ràng nhất bạn có thể làm là lập hồ sơ cho ứng dụng của bạn và tìm các nút cổ chai trong thời gian khởi động. Có vẻ như thủ phạm có khả năng nhất sẽ là tải dữ liệu từ cơ sở dữ liệu của bạn.Một bài học tôi đã học được là nếu bạn đang sử dụng ORM, khi tải các tập dữ liệu lớn nếu bạn ủng hộ POCO (Plain Old CLR/C# Objects) trên các thực thể cơ sở dữ liệu được tạo ORM (xem ví dụ bên dưới), tải thời gian sẽ nhanh hơn rất nhiều và sử dụng RAM sẽ giảm đáng kể. Lý do cho điều này là EF sẽ cố gắng tải toàn bộ thực thể (nghĩa là tất cả các trường của nó) và có thể tải toàn bộ dữ liệu liên quan đến các thực thể của bạn, hầu hết trong số đó bạn thậm chí sẽ không cần. Thời gian duy nhất bạn thực sự cần phải làm việc trực tiếp với các thực thể là khi bạn đang thực hiện các hoạt động chèn/cập nhật/xóa. Khi đọc dữ liệu, bạn chỉ nên chỉ nhận các trường mà ứng dụng của bạn cần hiển thị và/hoặc xác thực.

Nếu bạn theo mẫu MVVM, kiến ​​trúc trên không khó thực hiện.

Ví dụ về dữ liệu tải vào POCOs với EF:

var query = from entity in context.Entities 
       select new EntityPoco 
       { 
        ID = entity.ID, 
        Name = entity.Name 
       }; 

return query.ToList(); 

POCOs các lớp học rất đơn giản với autoproperties cho từng lĩnh vực.

Chúng tôi thường có kho lưu trữ cho từng thực thể trong các ứng dụng của chúng tôi và mỗi kho lưu trữ có trách nhiệm nhận/cập nhật dữ liệu liên quan đến thực thể đó. Các mô hình khung nhìn có tham chiếu tới các kho lưu trữ mà chúng cần để chúng không sử dụng EF trực tiếp. Khi người dùng thực hiện các thay đổi cần được duy trì, chúng tôi sử dụng các phương thức khác trong kho lưu trữ, sau đó chỉ tải một tập hợp con của các thực thể (ví dụ: những người dùng đã thay đổi) và áp dụng các cập nhật cần thiết - với một số xác thực được thực hiện bởi viewmodel và xác thực khác đang diễn ra trong DB thông qua các ràng buộc/trình kích hoạt, v.v.

Answer 3

Có nhiều lý do cho việc này.

1) Máy triển khai có thể có cấu hình khá thấp.
2) Đúng hoặc vấn đề với ràng buộc dữ liệu.

giải pháp có thể sẽ là:
1) Lazy tải dữ liệu
2) Tối ưu hóa hiệu suất. http://msdn.microsoft.com/en-us/library/aa970683.aspx

Tôi đã thấy các ứng dụng hiển thị bản ghi 5 triệu ít hơn một giây trong wpf.

PS: Một trong những lý do ít nhất có thể có thể là 30 cột, do truy cập thứ tự cột.