VB读文件真的好慢好慢!

我试了几种方法:
1.使用Open Fname for Input as #1,这种语句,使用 Input$(LOF(1),1),感觉上运行速度还可以,可惜好像只能读文件格式的文件.一行一行读就极慢了.
2.使用Open Fname for Binary Access可以读任意类型,但是速度真的好慢.
3.使用FSO读文件同样存在问题,一行一行的读准确率高,但是极慢,一次全部读入内存速度快,但遇到特殊格式的文本还是会出问题.大家有没有好的读文件的方法或者知道可以调用哪个API,一起讨论讨论吧.

解决方案 »

  1.   

    createfile,readfile,writefile,closehandle,等api函数
      

  2.   

    2.使用Open Fname for Binary Access可以读任意类型,但是速度真的好慢.速度不慢呀,你的代码怎么写的?
      

  3.   

    //使用Open Fname for Binary Access可以读任意类型,但是速度真的好慢.应该是你代码的问题
      

  4.   

    同意楼上，是搂主的代码问题
    你这样看看
    Dim FileInfo() As Byte
    Redim FileInfo(1 To FileLen("C:\XXXFile.MDB")
    Open "C:\XXXFile.MDB" For BinAry As #1
    Get #1,1,FileInfo
    Open "C:\XXXFile2.MDB" For BinAry As #2
    Put #2,1,FileInfo
    Close #2
    Close #1
    这是一个可以复制文件的范例，即使"C:\XXXFile2.MDB"是一两百MB
    都不会很慢。你是不是一个一个的读取呀，那坑定慢啦。
      

  5.   

    零时写的代码有点问题，呵呵
    Redim FileInfo(1 To FileLen("C:\XXXFile.MDB"))
      

  6.   

    Input$(LOF(1),1)等方法，有时会较慢，那是因为VB内部Unicode编码问题，只要涉及字符串，这些方法将内部进行隐含的ANSI到Unicode编码的转换，大量转换时非常耗时。可以说，在文件读写这种操作上，不管是用VB还是用API，或其它编程语言，只要方法得当，速度几乎都是一样的。
    因为它们均受限于硬盘速度，就象高档车与低档车，可在高速公路上竞速，但上了单行小路，大家都得一个个排队。这个观点，我一直坚持，但总觉同意者甚少，终于在不久前发现了一个重量级人物早就表达了这个态度，并坚定而自信到了极至！VB大师 Bruce McKinney 在《Visual Basic 5.0 核心技术》中有一段著名论述，正是基于此观点，看看有没有人为了让他“当众跪在地上向你作辑”，来进行这个==>       挑战人们普遍相信，通过使用诸如 ReadFile 和 WriteFile 这样的 API 调用，取代如带 Get 和 Put 的二进制 I/O 这样的 Basic 特性，可以加速 VisualBasic I/O。从 API 中可能得到的任何细微的优势都将被磁盘访问的代价冲掉。你怀疑吗？请证明我错了。我不会与事实争辩。如果有谁显示给我代码，说明 API 调用明显快于 Basic I/O，我会当众跪在地上向他作辑。我已在几个在线论坛上发布了这项挑战，但至今为止还没有人让我鞠躬。使用 API I/O 有其理由（与其他 API 调用的兼容性），但我坚持说速度不在其中。
      

  7.   

    参考
    http://www.chenoe.com/blog/blogview.asp?logID=1857
      

  8.   

    文本流就是你上面说的FSO。用TextStream 对象
    文件大读取自然耗时，总不可能希望他象1K文件那样吧，
    对显示来说，分段显示，后台加载会得到比较好的效果，很多文件编辑的软件都采用
    类似的方法，像WINHEX就是如此。
      

  9.   


     VB读写文件慢．．．怎么会呢 我写过一个函数，复制文件的，几百M的复制时间和Windows的没有什么太大差别
      

  10.   

    非常感谢大家！我的代码是有问题，后来我选择了用For Binary Access,我是在制作一个文件搜索工具，已经得到了较好的速度，可惜有时会出现Out of Memory的错误。