加快图像列表的加载速度
我正在从包含大约 250 张图像的文件夹中加载 List
。我进行了日期时间比较,加载这 250 张图像需要整整 11 秒。这太慢了,我非常想加快速度。
这些图像位于我的本地硬盘上,甚至不是外部硬盘上。
代码:
DialogResult dr = imageFolderBrowser.ShowDialog();
if(dr == DialogResult.OK) {
DateTime start = DateTime.Now;
//Get all images in the folder and place them in a List<>
files = Directory.GetFiles(imageFolderBrowser.SelectedPath);
foreach(string file in files) {
sourceImages.Add(Image.FromFile(file));
}
DateTime end = DateTime.Now;
timeLabel.Text = end.Subtract(start).TotalMilliseconds.ToString();
}
编辑:是的,我需要所有图片。我计划的事情是取出每个中心的 30 个像素列,并从中制作一个新图像。有点像360度的图片。只是现在,我只是用随机图像进行测试。
我知道可能有更好的框架可以做到这一点,但我需要它首先工作。
EDIT2:切换到秒表,差异只是几毫秒。还尝试了 Directory.EnumerateFiles,但没有任何区别。
EDIT3:我正在 32 位 Win7 客户端上运行 .NET 4。
I'm loading a List<Image>
from a folder of about 250 images. I did a DateTime comparison and it takes a full 11 second to load those 250 images. That's slow as hell, and I'd very much like to speed that up.
The images are on my local harddrive, not even an external one.
The code:
DialogResult dr = imageFolderBrowser.ShowDialog();
if(dr == DialogResult.OK) {
DateTime start = DateTime.Now;
//Get all images in the folder and place them in a List<>
files = Directory.GetFiles(imageFolderBrowser.SelectedPath);
foreach(string file in files) {
sourceImages.Add(Image.FromFile(file));
}
DateTime end = DateTime.Now;
timeLabel.Text = end.Subtract(start).TotalMilliseconds.ToString();
}
EDIT: yes, I need all the pictures. The thing I'm planning is to take the center 30 pixelcolums of each and make a new image out of that. Kinda like a 360 degrees picture. Only right now, I'm just testing with random images.
I know there are probably way better frameworks out there to do this, but I need this to work first.
EDIT2: Switched to a stopwatch, the difference is just a few milliseconds. Also tried it with Directory.EnumerateFiles, but no difference at all.
EDIT3: I am running .NET 4, on a 32-bit Win7 client.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您真的需要加载所有图像吗?你能避免延迟加载它们吗?或者,您可以将它们加载到单独的线程上吗?
Do you actually need to load all the images? Can you get away with loading them lazily? Alternatively, can you load them on a separate thread?
您无法加快硬盘访问和解码速度。然而,一个好主意是在后台线程中加载图像。
也许您应该考虑在图像实际加载之前显示占位符。
注意:无论如何,您都需要将加载的图像插入到 UI 线程中!
You cannot speed up your HDD access and decoding speed. However a good idea would be to load the images in a background thread.
Perhaps you should consider showing a placeholder until the image is actually loaded.
Caution: you'll need to insert the loaded images in your UI thread anyway!
您可以使用 Directory.EnumerateFiles 和 Parallel.ForEach 将工作分散到尽可能多的 CPU 上。
You could use Directory.EnumerateFiles along with Parallel.ForEach to spread the work over as many CPUs as you have.
由于加载图像同时需要文件 IO 和 CPU 工作,因此您应该通过使用多个线程来获得一些加速。
如果您使用 .net 4,那么使用任务将是最佳选择。
As loading a image does both file IO and CPU work, you should get some speadup by using more then one thread.
If you are using .net 4, using tasks would be the way to go.
鉴于您可能已经知道路径(从对话框中?),您可能最好使用 Directory.EnumerateFiles,然后使用它返回的集合而不是列表。
http://msdn.microsoft.com/en-us/library/dd383458.aspx
[编辑]
刚刚注意到您还在循环内将文件加载到应用程序中 - 它们有多大?根据它们的大小,它实际上可能是一个相当不错的速度!
此时您需要加载它们吗?您可以在其他地方更改一些显示代码以按需加载吗?
Given that you likely already know the path (from the dialog box?), you might be better using Directory.EnumerateFiles and then work with the collection it returns instead of a list.
http://msdn.microsoft.com/en-us/library/dd383458.aspx
[edit]
just noticed you're also loading the files into your app within the loop - how big are they? Depending on their size, it might actually be a pretty good speed!
Do you need to load them at this point? Can you change some display code elsewhere to load on demand?
您可能无法加快速度,因为瓶颈是从磁盘读取文件本身,并可能将它们解析为图像。
不过,您可以做的是在加载列表后对其进行缓存,然后对代码的任何后续调用都会快得多。
You probably can't speed things up as the bottle neck is reading the files themselves from disk and maybe parsing them as images.
What you can do though is Cache the list after it's loaded and then any subsequent calls to your code will be lot faster.