File I/O ?????


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: File I/O ?????

Hybrid View

  1. #1
    Gary Nelson Guest

    File I/O ?????

    Anyone understand what this means?

    Specifically, what class library are they refering to, who writes it, in
    what language, and how does it work? Why would anyone want to use a
    different I/O library?

    From Microsoft's white paper:

    File I/O
    Visual Basic 6.0
    File I/O statements are included in the language.
    Visual Basic.NET
    File I/O operations are available through class libraries. Removing the
    file I/O statements from the language allows different I/O libraries to be
    easily used from Visual Basic.NET. This would be more awkward if the file
    I/O statements were in the language, since identifiers like Open, Close,
    Print, and Write would be reserved words.
    Upgrade
    Wizard The file I/O statements are upgraded to the corresponding functions.
    For example, the following code:
    Open "MyFile.txt" For Input As #1
    is upgraded to:
    FileOpen( 1, "MyFile.txt", OpenMode.Input )





  2. #2
    David A. Rothgery Guest

    Re: File I/O ?????

    Gary Nelson <gn@contanet.es> wrote:
    > Anyone understand what this means?
    >
    > Specifically, what class library are they refering to,


    Mostly the .NET framework, but they also wanted to allow libraries
    written in vb.NET to have Open and Close methods, which would be at
    worst impossible and at best annoying if Open and Close were reserved
    words.

    > who writes it,


    Microsoft

    > in what language,


    C++ and/or C#

    > Why would anyone want to use a different I/O library?


    Because there are a lot of things that are a pain to do using the native
    VB6 I/O methods, and so have be done through API calls or the relatively
    new FileSystemObject.

    --
    Dave Rothgery
    Picking nits since 1976
    drothgery@myrealbox.com
    http://drothgery.editthispage.com

  3. #3
    Gary Nelson Guest

    Re: File I/O ?????

    David,

    >
    > Because there are a lot of things that are a pain to do using the native
    > VB6 I/O methods, and so have be done through API calls or the relatively
    > new FileSystemObject.
    >


    I suppose for a beginning programmer the I/O methods in VB6 can be a pain,
    but not to an experienced programmer. Since I've been programming since
    basic-a, I've designed all of my own database functions in pure BASIC (now
    VB6). I have many users that have databases with over half a milllion
    records, some over a million. Some have as many as 20 operators attacking
    the database simultaneously. Access times are about .001 second to find an
    indexed record (the indexes are b-tree, also made in pure VB), and in less
    than 20 seconds I can find any part of anything in the database. All of
    that is done in pure VB. Many people ignore that the file I/O methods in VB
    are extreemly efficient. It is absolutely impossible to do anything similar
    in Access. In my tests Access not only is too slow on the non-indexed
    searches (exponentially), but it crackes up after you get over five users on
    it.

    What does Microsoft want me to do, change to Delfi?

    Gary



  4. #4
    David A. Rothgery Guest

    Re: File I/O ?????

    Gary Nelson <gn@contanet.es> wrote:
    > David,
    >
    > > Because there are a lot of things that are a pain to do using the native
    > > VB6 I/O methods, and so have be done through API calls or the relatively
    > > new FileSystemObject.
    > >

    >
    > Since I've been programming since
    > basic-a, I've designed all of my own database functions in pure BASIC (now
    > VB6). I have many users that have databases with over half a milllion
    > records, some over a million. Some have as many as 20 operators attacking
    > the database simultaneously. Access times are about .001 second to find an
    > indexed record (the indexes are b-tree, also made in pure VB), and in less
    > than 20 seconds I can find any part of anything in the database. All of
    > that is done in pure VB. Many people ignore that the file I/O methods in VB
    > are extreemly efficient. It is absolutely impossible to do anything similar
    > in Access. In my tests Access not only is too slow on the non-indexed
    > searches (exponentially), but it crackes up after you get over five users on
    > it.


    MichKa, here's another 'Jet doesn't scale' guy to pick on...

    More seriously, I'm pretty sure that the old VB I/O functions are in
    either the compatibility namespace or the VB namespace, but you'll
    probably find the functions in System.IO to be more effecient and more
    powerful in vb.NET.

    --
    Dave Rothgery
    Picking nits since 1976
    drothgery@myrealbox.com
    http://drothgery.editthispage.com

  5. #5
    Gary Nelson Guest

    Re: File I/O ?????

    David,

    What gets me is why does Microsoft have to take funcionality out of the
    language, which takes little programming on their behalf, and gives us great
    headaches.

    I mean, I already had to create functions to emulate MKD, CVD, etc. when
    Microsoft took them out of VB. I am sure that MKD in assembler or C can be
    no more that two or three lines of code. Why kill it? Now I hear they are
    killing LSET. I mean, I use it for a lot of things. Now I have to create a
    function to emulate it. Again, how much code does LSET take???

    About Jet, try doing a secuencial search on a part of a field that isn't
    indexed on a million key database. You just as well got to lunch while you
    wait.

    Gary



  6. #6
    David A. Rothgery Guest

    Re: File I/O ?????

    Gary Nelson <gn@contanet.es> wrote:
    > David,
    >
    > What gets me is why does Microsoft have to take funcionality out of the
    > language, which takes little programming on their behalf, and gives us great
    > headaches.
    >
    > I mean, I already had to create functions to emulate MKD, CVD, etc. when
    > Microsoft took them out of VB. I am sure that MKD in assembler or C can be
    > no more that two or three lines of code. Why kill it? Now I hear they are
    > killing LSET. I mean, I use it for a lot of things. Now I have to create a
    > function to emulate it. Again, how much code does LSET take???


    vb.NET is a ground-up rewrite. And you should never do a ground-up
    rewrite of a large project unless you absolutely have to, because it's
    impossible to do without annoying a lot of your customers. Microsoft
    knows this, which is why they put off doing a ground-up rewrite of VB
    for so long. And they're going to annoy a lot of their best customers
    anyway.

    Because Microsoft actually has to ship vb.NET at some point, and they
    actually want to sell it, cool new features are going to be higher-
    priority than rarely-used features. You simply can't rebuild all the
    features of VB1 through VB6, add on all the functionality of a modern OO
    language, and build the .NET class libraries in a decent timeframe. Half
    the reason for the whole CLR/.NET framework, IMO, is so that Microsoft
    only has to build one class library, instead of three or four. Microsoft
    may have more resources than any other software company, but those
    resources are still finite.

    For a programming language, rarely-used features that academic computer
    scientists -- and the young people who with CS degrees at Microsoft --
    consider to be evil, patheitc hacks, Microsoft won't think very long
    about cutting them. LSet, GoSub, and the like are those kind of
    features. That doesn't mean that you don't find them useful, or that
    they're never useful, but they're the kind of construct that I'd never
    even consider using because I just wouldn't think of it.

    --
    Dave Rothgery
    Picking nits since 1976
    drothgery@myrealbox.com
    http://drothgery.editthispage.com

  7. #7
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

    "Gary Nelson" <gn@contanet.es> wrote in message <news:3a92a328@news.devx.com>...

    > About Jet, try doing a secuencial search on a part of a field that isn't
    > indexed on a million key database. You just as well got to lunch while you
    > wait.


    What did the code look like? There are a number of pretty straightforward
    tricks that do speed things up quite a bit, such as creating aliases for
    frequently accessed fields so you aren't constantly hitting the Fields
    collection.

    --
    Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  8. #8
    Gary Nelson Guest

    Re: File I/O ?????

    MichKa,

    > Oh, how very fair and accurate of a report. Compare your b-tree index

    system
    > to unindexed rows. Is that how you need to convince yourself that your own
    > way is better?


    In my post I said:

    <<Access times are about .001 second to find an
    indexed record (the indexes are b-tree, also made in pure VB), and in less
    than 20 seconds I can find any part of anything in the database. >>

    The 20 seconds is on an unindexed row as you call it.

    Gary




  9. #9
    Gary Nelson Guest

    Re: File I/O ?????

    Joe,

    > What did the code look like? There are a number of pretty straightforward
    > tricks that do speed things up quite a bit, such as creating aliases for
    > frequently accessed fields so you aren't constantly hitting the Fields
    > collection.


    Actually it's not really very hard to do. Open the file in binary, read in
    64K segments, use INSTR to find what your looking for (case sensitive is
    incrediblly fast, case insensitive takes a little longer), calculate what
    record you have hit, and pull the whole record. I just did a test to time a
    search. A database with 326,265 records, 47 MB in size, a secuencial search
    can done be done on a non indexed field in a little less than 8 seconds, and
    that is on my old 300 mhz. notebook. A case insensitive search (look for
    John and pick up john or JOHN) took a little over 30 seconds. A search for
    a double precision number both positive and negative takes about 12 seconds.

    I use the rutine on my own databases, but it can also be used on DBase
    files, and I have also used it on Btrieve files. Btrieve files take a little
    more work as you have to filter the index pages, but it is still very
    efficient. (My brother works with Btrieve, and has a shareware program to
    handle the files). Once I asked Microsoft for the internal structure of the
    Access database to build a rutine to do the same, but they wouldn't give it
    to me, and I wasn't in the mood to crack it (besides which they change it
    too often).

    Let me know if you want a copy of the code, it's only about 30 lines long.

    Gary







  10. #10
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

    "Gary Nelson" <gn@contanet.es> wrote in message <news:3a96af73@news.devx.com>...

    > Joe,
    >
    > > What did the code look like? There are a number of pretty straightforward
    > > tricks that do speed things up quite a bit, such as creating aliases for
    > > frequently accessed fields so you aren't constantly hitting the Fields
    > > collection.

    >
    > Actually it's not really very hard to do. Open the file in binary, read in
    > 64K segments, use INSTR to find what your looking for (case sensitive is
    > incrediblly fast, case insensitive takes a little longer), calculate what
    > record you have hit, and pull the whole record. I just did a test to time a
    > search. A database with 326,265 records, 47 MB in size, a secuencial search
    > can done be done on a non indexed field in a little less than 8 seconds, and
    > that is on my old 300 mhz. notebook. A case insensitive search (look for
    > John and pick up john or JOHN) took a little over 30 seconds. A search for
    > a double precision number both positive and negative takes about 12 seconds.


    Sorry, I was asking about the "go to lunch" slow Jet code. However,
    just how smart is the InStr builtin, anyway? There's a way to examine
    only every Len(string2)-th character in string1 instead of every
    character, but in this case, the disk access times will probably
    overwhelm anything gained by a smarter InStr.

    --
    Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  11. #11
    Gary Nelson Guest

    Re: File I/O ?????

    Joe,

    > However,
    > just how smart is the InStr builtin, anyway? There's a way to examine
    > only every Len(string2)-th character in string1 instead of every
    > character, but in this case, the disk access times will probably
    > overwhelm anything gained by a smarter InStr.



    A$=space$(65534)
    B$="Find Me"
    open "Filename" for binary as 1
    do while not eof(1)
    get 1,,a$
    if instr(a$,b$)<>0 then
    ' use seek to find where you are
    ' separate record, etc.
    end if
    loop

    Gary



  12. #12
    Sjoerd Verweij Guest

    Re: File I/O ?????

    > A$=space$(65534)
    > B$="Find Me"
    > open "Filename" for binary as 1
    > do while not eof(1)
    > get 1,,a$
    > if instr(a$,b$)<>0 then
    > ' use seek to find where you are
    > ' separate record, etc.
    > end if
    > loop


    That's interesting. What if my record length isn't a factor of 65534 and the
    string to be found is split?



  13. #13
    Gary Nelson Guest

    Re: File I/O ?????

    > That's interesting. What if my record length isn't a factor of 65534 and
    the
    > string to be found is split?
    >



    There are two different things you can do. First I chose 65534 because
    exact multiples of cluster sizes read faster from the hard disk, but it is
    not necessary to do so. You can read a multiple of your record length, or
    you can take into consideration that the last record in the string is not
    complete.

    The string doesn't have to be that large either. Sometimes around 32K
    produces faster results. Or the exact cluster size of the hard disk in
    question.Generally strings larger than 64K slow down as VB has a harder time
    handling them.

    Gary



  14. #14
    Gary Nelson Guest

    Re: File I/O ?????


    > Nah, no picking. I just resign myself to the fact that some people just
    > don't know how to do stuff.
    >
    > After all, he did compare his proprietary index system to an unindexed
    > million row table. So he must know what he is talking about. I am sure his
    > database system provides all of the features and all of the connections to
    > other data sources/encodings that Jet does too.
    >

    MichKa,

    Like decent record locking. Actually, my database includes field locking,
    permitting multiple users to update different fields of the same record
    simultaneously.

    Or how about reading an individual field of a record of a database without
    reading in the entire record. Or how about updating an individual field of
    a database without touching the rest of the record.

    Gary




  15. #15
    Rune Bivrin Guest

    Re: File I/O ?????

    And 65534 is an exact multiple of which cluster size?

    Rune
    "Gary Nelson" <gn@contanet.es> wrote in message
    news:3a9a5d03@news.devx.com...
    > > That's interesting. What if my record length isn't a factor of 65534 and

    > the
    > > string to be found is split?
    > >

    >
    >
    > There are two different things you can do. First I chose 65534 because
    > exact multiples of cluster sizes read faster from the hard disk, but it is
    > not necessary to do so. You can read a multiple of your record length,

    or
    > you can take into consideration that the last record in the string is not
    > complete.
    >
    > The string doesn't have to be that large either. Sometimes around 32K
    > produces faster results. Or the exact cluster size of the hard disk in
    > question.Generally strings larger than 64K slow down as VB has a harder

    time
    > handling them.
    >
    > Gary
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center