| 317 | | |
| | 317 | • the one character per call case is an extreme one which wouldn't commonly occur.[[br]] |
| | 318 | • the 10 and 20 char per call cases would simulate the writing of an XML file. The !FdoXmlWriter invokes FdoIoTextWriter::Write() for each XML fragment and most fragments would be in the neighbourhood of 20 char.[[br]] |
| | 319 | • larger XML fragments could be as large as 100 characters, so this case was also tested. [[br]] |
| | 320 | • 4000 characters is close to the FdoIoCachedStream default buffer size.[[br]] |
| | 321 | • the 8000 and 50000 character cases were tried to see if any benefits could be realized by increasing the default buffer size.[[br]] |
| | 322 | |
| | 323 | If we assume that the average XML fragment size is 20 bytes, then a 10X improvement in writing XML to files would be realized. Even in the extreme case, where all fragments are large (100 char), there is an approximate 2.5X improvement. |
| | 324 | |
| | 325 | There does not appear to be any benefit to raising the default buffer size. The 8K buffer would provide the same performance. The 50K buffer is actually slower. FdoIoTextWriter::Write() takes a wide-char string and converts it to UTF8 before writing it. This conversion overhead might start to be significant at the higher buffer sizes, which may explain the slowdown. |
| | 326 | |
| | 327 | In conclusion, !FdoIoCachedStream provides significant performance benefits when writing to XML. |
| | 328 | |
| | 329 | |
