|
|
It works and all is ok. but this problem was not before. My AppXMLStorage xml file is sized aproximetly 1-2MB (differs from workstation to workstation) |
|
|
I have the same problem, but i'm not able to figure it out. I've tried to analyze with aqtime, but i was not so successfull. I've attached some screenshots of aqtime statistics. Any help is welcome :-) Greetings Jens |
|
|
Can you guys try to find which revision in the JCL introduced this? |
|
|
JclSimpleXML: http://jcl.svn.sourceforge.net/viewvc/jcl/branches/JCL_1.103/jcl/source/common/JclSimpleXml.pas?view=log#rev2462 Revision 2462 (Broken - works 100x slower) Modified Tue Sep 9 19:32:52 2008 UTC (8 weeks, 2 days ago) by outchy support for Delphi 2009 and C++Builder 2009 with native Unicode support: - native Unicode support; - update to Unicode Character Database 5.1.0; - introduction of string streams with automatic conversions. Revision 2460 (This works fine like old good..) Modified Tue Sep 9 11:12:36 2008 UTC (8 weeks, 3 days ago) by outchy preparation of the preview for Delphi 2009 and C++Builder 2009. |
|
|
Starting of this revision, JclSimpleXml is able to load XML files with various encoding (UTF8, UTF16, ANSI), the conversion functions are taking a lot of time there. Maybe they could be fine tuned... |
|
|
Hi Olivier, it's not only the reading, the writing is realy slowly. It can take more then a minute to write a file with 500k. Greetings Jens |
|
|
For the situation Delphi 2007 + Ansi Encoding TJclStringStream.PeekChar and TJclStringStream.ReadChar consume almost all of the time. I compared the reading speed of the current revision (2514) with revision 2293 and it is 3 times slower. With a very simple version of PeekChar and ReadChar (just read a byte + Chr) it was faster then revision 2293. |
|
2008-11-07 13:57
|
flush_editor.png (291,447 bytes) |
|
2008-11-07 13:58
|
loadbuffer_editor.png (156,139 bytes) |
|
2008-11-07 14:00
|
callgraph.png (147,674 bytes) |
|
|
I've added now some of the screenshots from AQTime. |
|
|
Only 2462 revision started to work slowly. 2460 works perfect. |
|
|
An other interesting point is: reading is much faster then writing. |
|
|
The main problem is that the JclStringStream is more busy converting byte sequences to UCS4 and back than reading/writing the actual data. |
|
|
Does anyone has a chance to look into this ? |
|
|
I had a look at the writing issue and the problem is that TJclBufferedStream is not suitable for writing, because it always tries to load the buffer although there is nothing to load for a new file. Furthermore setting the BufferSize to 1 does not help, because the buffer starts at the last write position and TJclBufferedStream is trying to load a byte at the new position into the buffer, that fails and doesn't make sense, because the byte will be overwritten afterwards. For the following example the speed with TJclBufferedStream is three times lower than using the TFileStream directly var FS: TFileStream; BS: TJclBufferedStream; B: Byte; I: Integer; begin FS := TFileStream.Create('Testfile', fmCreate); try BS := TJclBufferedStream.Create(FS, False); try B := 0; for I := 0 to 1048575 do BS.Write(B, 1); finally BS.Free; end; finally FS.Free; end; end; |
|
|
The following change brings the write speed back, but I am not yet sure if this change is correct. change if not BufferHit then LoadBuffer; in TJclBufferedStream.Write in JclStreams.pas into if not BufferHit then begin if (FBufferStart <= FPosition) and (FPosition < (FBufferStart + FBufferSize)) then begin if Length(FBuffer) <> FBufferSize then SetLength(FBuffer, FBufferSize); end else LoadBuffer; end; |
|
|
I've committed the suggested JclStreams change from 0004570:0015123 as revision 2575. Does this fix the write speed issue? |
|
|
For me it looks much better now. Thanks Uwe. |
- Anonymous
