[M3devel] EXT Re: EXT Re: AND (., 16_ff). Not serious - or so I hope!

[Coleburn, Randy]

I am willing to run tests on platforms that I have, mostly Windows flavors.
--Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Tuesday, June 26, 2012 5:42 PM
To: m3devel at elegosoft.com
Subject: EXT Re: [M3devel] EXT Re: AND (., 16_ff). Not serious - or so I hope!



On 06/26/2012 03:22 PM, Coleburn, Randy wrote:
> I seem to recall that Rodney did some work a while back relating to TEXT.
>
> Rodney, can you weigh in on some of this?
>

I wrote a modified implementation of cm3 TEXT.  It uses the same data structure and invariants, so any internal values it creates are useable by any existing code that imports the various revelations.  It improves performance problems deriving from Cat operations' building trees that actually degenerate into linear lists (fairly likely, as it happens whenever a string is constructed by a left-to-right or right-to-left series of concatenations.)  As usual, some operations on some values are slower, but it seems to be a gain overall.

I have an extensive test driver and statistics gatherer, which shows good results.  However, only tested it on LINUXLIBC6 and AMD64_LINUX, machines I have.  Olaf was not comfortable that it was fully tested this way, and I have never taken the time to figure out how to run tests on targets I don't have.

I think it is a significant improvement over the stock cm3 TEXT implementation.
Whether it is as good as just going back to the pm3 implementation is not so clear.

All three implementations correctly (except for possible bugs--none known at present, AFAIK) implement the language's abstract Text interface, and code that only uses Text would see only performance differences.


> --Randy Coleburn
>
> *From:*Dragiša Durić [mailto:dragisha at m3w.org]
> *Sent:* Tuesday, June 26, 2012 12:46 PM
> *To:* Jay
> *Cc:* m3devel
> *Subject:* EXT Re: [M3devel] AND (., 16_ff). Not serious - or so I hope!
>
> You had idea in other message. Store length!
>
> Another idea - store partial list of indices to character locations. So whatever one does, that list can be used/expanded. Whatever storage issues this makes, they are probably minor as compared to 32bit WIDECHAR for all idea.
>
> Mika had performance problems with cm3 TEXT. I hope he follows and cares to refresh us on those issues?!
>
> On Jun 26, 2012, at 6:34 PM, Jay wrote:
>
>
>
> I'm torn on that. We'd have to consider ramifications like Text.Length vs buffer size requirements/expectations.
>
> Is TEXT & its use abstracted enough to have been widened? Should we put it back and introduce WIDETEXT? That is essentially what C and C++ do. They are inconvenient for existing code but simple predictable make sense. Contrast with weird hybrid systems like Perl & Python for which I just can't get through the documentation and understand and predict how they work..
>