Reads data for a very long time

[MaximKutovoy]

I tried to read a file with a size of 725 kb. Reads data for a very long time. See screenshot http://joxi.ru/1A5MKRyuGK3vWA

A 1462 kb file was read for 16 minutes.

I attach file for test
files_for_test.zip

You can write me to skype or email

[Trinitek]

Yes, the performance is noticeably bad even for 1000 record * 80 column files. The upcoming 6.0 release should see some small improvements, but I will take a serious look at performance for 6.1.

Are you using the latest release build or the commit I mentioned in #1 (comment)?

[Trinitek]

Some notes for myself:

rooms.tps

Records: 13323
Columns: 7
Record Size: 64 bytes
Schema:

                   FILE,DRIVER('TOPSPEED'),NAME('rooms.tps')
ROM:BY_HOUSE         KEY(+ROM:ID_BUILD,+ROM:FLAT),DUP,NOCASE,OPT
ROM:BY_ACC           KEY(+ROM:ACC,+ROM:IDR),DUP,NOCASE,OPT
RECORD               RECORD
ROM:ID_BUILD           BYTE
ROM:FLAT               STRING(7)
ROM:ACC                STRING(10)
ROM:IDR                STRING(3)
ROM:NAME               STRING(30)
ROM:TYP                STRING(10)
ROM:SQW                DECIMAL(5,2)
                     END

svcntbld.tps

Records: 25262
Columns: 12
Record Size: 50 bytes
Schema:

                   FILE,DRIVER('TOPSPEED'),NAME('svcntbld.TPS')
SVC:BY_HOUSE         KEY(+SVC:MONTH,+SVC:ID_BUILD,+SVC:NPP,+SVC:VT),NOCASE,OPT
SVC:BY_MON           KEY(+SVC:MONTH,+SVC:NPP,+SVC:VT,+SVC:ID_BUILD),DUP,NOCASE,OPT
RECORD               RECORD
SVC:MONTH              LONG
SVC:ID_BUILD           SHORT
SVC:NPP                BYTE
SVC:VT                 BYTE
SVC:TELO               GROUP
SVC:SUM_CNT              DECIMAL(11,2)
SVC:SUM_CNG              DECIMAL(11,2)
SVC:NACH                 DECIMAL(11,2)
SVC:UBT                  DECIMAL(11,2)
SVC:UBT_CORR             DECIMAL(11,2)
SVC:NACH100              DECIMAL(11,2)
SVC:OPLATA               DECIMAL(11,2)
                       END
                     END

[MaximKutovoy]

Yes, the performance is noticeably bad even for 1000 record * 80 column files. The upcoming 6.0 release should see some small improvements, but I will take a serious look at performance for 6.1.

Are you using the latest release build or the commit I mentioned in #1 (comment)?

I have to change your code for use it in .Net 4.5.2. Maybe you could make a Nuget package for .Net 4.5.2 as well?

Could you make a constructor in which the encoding would be set?

[Trinitek]

I could (and should) expose a parameter in the TpsParser constructor, but there needs to be a way to load the default ISO-8859-1 encoding from within the library. From my testing, this is only possible using versions of System.Text.Encoding.CodePages that target .NET Standard 1.3 and later, which .NETFx 4.5.2 does not implement.

[Trinitek]

Slight correction, the CodePages package is required by the key decrypter, which uses Windows-1258 for passwords. (Vietnamese? I wonder if that was something being used for testing in the original Java library.) Considering the decrypter was implemented as-is during my port from the Java version and is not used by the parser at all, I think it is safe to remove this entirely.

In the far future, I think it would be nice to include it again in case someone needs to recover old TPS files. (I hear the newer TPS format switched to AES as the older algorithm only used 64-byte keys.)

In that case, we can drop the package and you can use it on .NETFx 4.5.2.