LC7 & Unicode

[TEDennis]

Paul: Thanks for the response.

I asked: "/Can we turn off that /[Unicode]/ detection, thus eliminating
Unicode processing?/"

You replied: "/No, this has been asked several times on the list, it's part
of the internal processing that LC uses and is too deeply embedded to
eliminate/".

I have been watching this forum for many moons, but usually don't have much
to say.  I have seen MANY questions asked about whether an option was
available to turn off the Unicode "feature".  I have seen the responses, all
of which were negative.  OK, fine.  LC7 can't live without Unicode.  If
Unicode is what's behind the performance glitches, then that's most
certainly not the answer I want to hear.  But, life goes on.

My question arose from Dr. Brett's claim that "/the LC7 engine only uses
Unicode if it has to/". 

That was news to me, and it made it sound to me like the engine was somehow
detecting Unicode being used.  That's why I asked if we could disable that
detection, and thus effectively disable Unicode processing.

I envisioned a bazillion places in the engine's code where it might say "If
gUnicodeGlobal is true then ... else ...".

I hope there aren't a bazillion places where the engine determines it has to
use Unicode, because that would require a bunch of needless CPU cycles that
could be reduced to referencing a single global (like above).

Perhaps my logical view of the situation was incorrect, but I (we) can hope,
right?

re: "/this sounds like the type of case that the engineers are asking to
see/"

Agreed.  That sounds like the next step in the resolution of "my" problem. 
But, none of them responded, so I got the feeling they weren't interested. 
If they need some example data, I can spend the time to extrapolate some
records during a test run within the IDE.  However, the explanation of
concatenating native strings to a few binary bytes should give them enough
info to say "yes" or "no" about the engine's detection of Unicode ... which
I hoped could be turned off, so no matter what info I use would bypass the
Unicode processing.

If that's not the case, then ...

... we're back to square one, meaning I/we have to live with Unicode's
performance issues.

I'm wondering how a feature like Unicode that has had a major performance
impact managed to get past the initial design stage, but that's a different
issue altogether.  Surely somebody, somewhere foresaw this "enhancement"
would be a major resource hog.

TED



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690262.html
Sent from the Revolution - User mailing list archive at Nabble.com.