Hi, this is a very well known "problem" with UNIFACE strings, which is deeply embedded in the way strings are handled in the Kernel. The "trick" is not to let the string grow too much: just use a filedump/append now and then to offload a big chunk of the string and start with a "clean" string again. At the end, just file_load the longstring. Note: filedump/append has some overhead as well, so it pays off only when the chunks are big enough. Its worth a test. Success, Uli

Moin Ulrich, its allways nice to get feedback on posted stuff. Strings are definatly the bottlenek ... ! Using a file is of course a workaround, but that won't do when using xml for reading and transferring entity-data (lager than 10kb in a stateless environment). This puts me back to windows 3.1 where 80 percent of your harddrive turned to be .ini and .tmp files ;))) *bwaaaaaah* We gave the filedump-thing a try lately and tested the same functionality with and selfmade-3gl which handled the data. Outstanding performance ... but as i already mentioned this would demand a huge amount of files, wellorganised and after all we move away from the "normal" way to handle data :) Just imagine how many temp-files you produce while working with 5 entities (read and write) multiplied by lets say 25 clients at same time! And having finished that thought: What about the integrity of the data!? Need sensible data? just copy the tempfiles- the wellformed xml will make it easy! :))) ... Maybe i should build another 3gl which only samples large-strings and returns them in ONE piece ... Thx for reading this -GHAN-

Hi G?nter Here is a modification of your example with a nearly linear performance Trigger from Form: A_LONGTEXT ****** Y4:: ****** entry LONG1 1 variables 2 string vString 3 endvariables 4 X_TEXT = "%%X_TEXT%%%Long1 start : %%$clock" 5 $1=1 6 while($1 < 1000) 7-1 $2 = 1 8-1 while ($2 < 180) 9-2 vString = "%%vString%%%XMLTEEEEEEEEEEXT"; ### simulating a XML-Tag 10-2 $2 = $2 + 1 11-2 endwhile 12-1 $1 = $1 + 1 13-1 message/hint "%%$clock%%% %%$1%%%" 14-1 endwhile 15 X_TEXT = "%%X_TEXT%%% End : %%$clock%%^" 16 end ; long1 ****** entry LONG2 1 variables 2 string vString, vBuffer 3 endvariables 4 X_TEXT = "%%X_TEXT%%%Long2 start : %%$clock" 5 $1=1 6 while($1 < 1000) 7-1 $2 = 1 8-1 vString = "" 9-1 while ($2 < 180) 10-2 vString = "%%vString%%%XMLTEEEEEEEEEEXT"; ### simulating a XML-Tag 11-2 $2 = $2 + 1 12-2 endwhile 13-1 vBuffer = "%%vBuffer%%%%%vString%%%" 14-1 $1 = $1 + 1 15-1 message/hint "%%$clock%%% %%$1%%%" 16-1 endwhile 17 X_TEXT = "%%X_TEXT%%% End : %%$clock%%^" 18 end ; long2 if I have some time, i will check if the same improvement can be achieved working with the UXMLWRITER. Success, Uli

Hi Chang, with UXMLWRITER the thing is that it allocates more memory on the fly once the xml document become bigger and bigger. The first time you generate such a big XML document (5.5Mb) it really needs a lot of time to allocate this memory space. A second time you use the same instance of the UXMLWRITER component it should be a lot faster. So, if you can, always reuse the UXMLWRITER instance for your (big) XML write actions. Maybe this helps.

Thanx for the hint, Gerton! But the reading Component is a standalone Service, delivering the XMLdata to anyone, who requests for it. Stateless Environment! And so ... this won't do :) I guess, there is no real solution for this Problem. But while talking about allocation ... how does XMLLOAD/SAVE handle this? those two never seem to slow down! regards to the netherlands -GHAN-