Visual Basic/VB, Fixed-length strings are slow, especially long ones.

Fixed-length strings are slow, especially long ones.

Author	Message
NadCixelsy #1 / 4	Fixed-length strings are slow, especially long ones. I read a binary file with multiple GETs into a string. If the buffer is "DIM SBUFFER AS STRING * 60000", it takes 500-600 "GET #176, bufloc, SBUFFER" to read a 30 megabyte file. It takes about 8 seconds to do so. If I shrink the buffer size (say to 30000), the number of GETs increases (as expected), but the elapsed time is reduced to about 5 seconds. If, on the other hand, I specify, "DIM SBUFFER AS STRING" to create a dynamic string, thence "SBUFFER = SPACE$(60000)" to set the buffer size, the 500-600 GET statements now take less than two seconds. The elapsed time is pretty much the same regardless of the string's length. I would have thought that it would be the other way around.
Sat, 04 May 2013 02:55:40 GMT

David Kerbe #2 / 4	Fixed-length strings are slow, especially long ones. In article <3f3b17f9-e7c3-4d41-8e8c- Quote: > I read a binary file with multiple GETs into a string. If the buffer > is "DIM SBUFFER AS STRING * 60000", it takes 500-600 "GET #176, > bufloc, SBUFFER" to read a 30 megabyte file. It takes about 8 seconds > to do so. > If I shrink the buffer size (say to 30000), the number of GETs > increases (as expected), but the elapsed time is reduced to about 5 > seconds. > If, on the other hand, I specify, "DIM SBUFFER AS STRING" to create a > dynamic string, thence "SBUFFER = SPACE$(60000)" to set the buffer > size, the 500-600 GET statements now take less than two seconds. The > elapsed time is pretty much the same regardless of the string's > length. > I would have thought that it would be the other way around. Are you asking a question, or just making an observation? D
Sat, 04 May 2013 05:37:59 GMT

Karl E. Peterso #3 / 4	Fixed-length strings are slow, especially long ones. It happens that NadCixelsyd formulated : Quote: > I read a binary file with multiple GETs into a string. If the buffer > is "DIM SBUFFER AS STRING * 60000", it takes 500-600 "GET #176, > bufloc, SBUFFER" to read a 30 megabyte file. It takes about 8 seconds > to do so. > If I shrink the buffer size (say to 30000), the number of GETs > increases (as expected), but the elapsed time is reduced to about 5 > seconds. > If, on the other hand, I specify, "DIM SBUFFER AS STRING" to create a > dynamic string, thence "SBUFFER = SPACE$(60000)" to set the buffer > size, the 500-600 GET statements now take less than two seconds. The > elapsed time is pretty much the same regardless of the string's > length. > I would have thought that it would be the other way around. Well, wrong. As you found. Fixed length strings are an anachronism. But then, so are strings (period!) for file i/o. About 15 years ago, Unimess changed everything. You should only use byte arrays for this sort of activity. -- .NET: It's About Trust! http://vfred.mvps.org
Sat, 04 May 2013 07:27:05 GMT

Nobod #4 / 4	Fixed-length strings are slow, especially long ones. Quote: >I read a binary file with multiple GETs into a string. If the buffer > is "DIM SBUFFER AS STRING * 60000", it takes 500-600 "GET #176, > bufloc, SBUFFER" to read a 30 megabyte file. It takes about 8 seconds > to do so. > If I shrink the buffer size (say to 30000), the number of GETs > increases (as expected), but the elapsed time is reduced to about 5 > seconds. > If, on the other hand, I specify, "DIM SBUFFER AS STRING" to create a > dynamic string, thence "SBUFFER = SPACE$(60000)" to set the buffer > size, the 500-600 GET statements now take less than two seconds. The > elapsed time is pretty much the same regardless of the string's > length. > I would have thought that it would be the other way around. You may have to repeat your tests, especially the first one. The file maybe cached by the system, so to get consistent results, do your tests when the file is always cached(to measure VB/OS overhead), or restart after each test, or try copying or reading very large files so the cache is thrown away.
Sat, 04 May 2013 08:13:44 GMT

Page 1 of 1

[ 4 post ]