Ok, since nobody else speaks up:

Can the two of you please buy boxing gloves and take your fight to a ring?

Hi Martin,

the point is to make xml-compliant data. Since xml consists of these chars, it could mess up the whole xmlstream. If you wan't to go and form the xml itself, then i recommend you to do the whole thing without the uxml-writer ... (so did I by time). Beware of the STRING-ISSUE- ... as you might know, Uniface slows down when strings get to big.

Maybe this could help you on your way!?

Cheers,

-GHAN-

Hi martin,

(the /notranslate is a missing feature, but in the meantime:) let's just  turn processing around:

1) offload the XML buffer and
2) append the buffer to a local buffer string

3) Translate the critical caracters to whatever you like: < turns to -lt- etc.
4) Put the translated string to the XMLWRITER
5) offload the XML buffer (holds only your just entered info, so it is small)
6) re-translate the string returned from XMLWRITER: -lt- turns to < etc.
7) append the retranslated info to a local buffer string

8) continue with the "non-CDATA" processing.

XMLWRITER performs much better if you offload the buffer from time to time
and append it to your own result string.
So now downgrade when writing large XML files
 

Success, Uli

There are not problems of uniface with very long strings,
but underperforming algorithms/implementations by local uniface coders (in most cases)

Proof to SLOW STRINGS in Uniface

I hope you know, what you are writing here and there :

There are not problems of uniface with very long strings,
but underperforming algorithms/implementations by local uniface coders (in most cases)

Remember last year in September? :) I will refresh your memory with on of your former posts:

ulrich-merkel Posts: 126 Registered on: Jun 12, 2008

RE: Uniface getting slow-motion with bigger Strings Posted: Sep 2, 2008  5:26 PM 16 views In reply to: Uniface getting slow-motion with bigger Strings — Hi everybody, ... posted by -GHAN- on Aug 29, 2008  11:34 AM 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

Tztztztz ... if you still don't believe it, feel free to reREAD the thread

Forum > Uniface Development > Uniface 9 > Uniface getting slow-motion with bigger Strings

We got a Bugfix once on this, but this didn't work out that good. So, the problem persists.

-GHAN- ... still laughing !

if you had only spend 15 secs more to read the complete text (see the orange one):

This Thread is getting OFFTOPIC!

< OFFTOPIC >
@Merkel:

But YOU pointed out that, there are no problems with Strings in Uniface :) IF SO then why do we have to dump the strings on disk in order to keep Uniface at normal speed?! ;) You must admit, that this is because of the problem in Uniface and the memory-allocation which persists since V7 ... right or wrong?! :)

So, what is a user supposed to believe after reading all this "THERE IS A PROBLEM - THERE Is NO PROBLEM"-crap?

We won't come nowhere- never ever! Not even if you go latin or whatever ... and I'm pretty fine with that.
< / OFFTOPIC >

(the following part is related to the topic and worth reading!)

@Martin:

From the time where i was running in to this problem I can say:

1) UXMLWRITER is known to slow down like any other component aswell while generating large strings due to the way Uniface handles long strings internally

2) This is a Uniface specific behaviour, which is not a user fault or has it's roots in the way you design your code. The user just produces a xmlstream. No bad intensions here :)

3) There is a patch available (V9.2.03 O303 or somewhere there if I remember right) which increases the limit of the buffersize from 10kb to10MB and helps a bit. But on this is still far from fast! Faster than normal but not as fast as recommending to fasten the seatbelts ;)

4) making custom XMLstreams increases the possiblities while it could slow down the app depending upon how large the xmlstream grows. (got an entity here with 80 Fields and 8112 occs. Taking only 2 fields and making a custom stream of it took very long ... (30+ minutes) while a custom code made it in about 7 sec's)

so far from me- hope this could help u out a bit
No further comments from me on this thread (not even the crappy otftopics with the merkeldude) :)) ...

TGIF! ("Thank God Its Friday" for those who aren't familiar with the acronymes)

-GHAN-

So then why do we have to dump the strings on disk in order to keep Uniface at normal speed?!

Why? because this is the appropriate algorithm for this context (aka. the one with the better performance)

I developed the first suggestion for a friend who needed a XML file at the end;
but as I documented on sep-3rd flushing the working string to a
collector string from time to time will provide the same speed as using a filedump.

Important to consider this has nothing to do with  memory allocation,
because the 2nd test is +/- as slow as the first one.
Therefore offloading the XMLstring in chunks of 10 GB instead of 10 KB does not solve the situation.

Success, Uli

Very similar to of recursive algorithms (shell- quick-) instead of a bubble sort.

... spending 3 minutes more to read the next 2
post in that thread would have revealed that
using filedump is not the only way to speed up the processing;
but if you want an XML-file at the end, this is the way to go.

On the very same day (080903) I heard about the outstanding performance of my proposal,
but as well that the filedump is a nogo because the XML-string should be used internally,
I replied with a variation of the democode using a buffer-string instead of the filedump.

Running the example code for 100 outer loops on my machine took some awful 124 secs.
Introducing one string offload per outer loop reduced it to some 2 secs (> 98 % reduction).

Using XMLWRITER you get the generated XML in tranches and accumulate them in a string.
The longer the XMLstring the slower it goes.

But think first (successful programming is all about choosing the best-fit algorithm):
- We know a very long XML string inside the XMLWRITER will degrade performance
- We know that writing an XML is a sequential process
- We know that we can get the current XML substring anytime we want
Why not flush the generated XML from time to time and accumulate them in our string?
It's the same logic as in my introduction of the buffer which caused a > 98 % reduction of processing time.

Success, Uli

BTW: due to my initiative, Mike Zille presented this as a booster on his
XMLWRITER workshop at the CBG-meeting in Stuttgart last year.