On 02/20/2014 08:29 AM, Brad Gilbert wrote: > On Wed, Feb 19, 2014 at 11:43 PM, Konovalov, Vadim > <Vadim.Konovalov@emc.com> wrote: >>> From: Karl Williamson [mailto:public@khwilliamson.com] >>> But as it turns out, I agree with him. Unless we can get a regular smoke >>> facility, there's no point in trying to support EBCDIC. >> >> Indeed. >> >> from technical POV - this support UTF-EBCDIC - while it obviously costs some >> maintenance efforts - does it cost any CPU speed for non-EBCDICs? >> > > We are only talking of removing official support for it. > > That doesn't mean that any of the code will be ripped out immediately. > Although I wouldn't bet on it staying in for long. > > Really once it is removed, it would be easier to see ways of improving the code; > so it is possible that it does cost CPU speed in ways we can't yet see. > I can't think of any performance penalties for having EBCDIC that aren't negligible. There are known optimizations that haven't been applied, but these could be enhanced to also work for EBCDIC, or be #ifdef'd.Thread Previous | Thread Next