Re^4: Slow find/replace hex in Perl win32

Replies are listed 'Best First'.
Re^5: Slow find/replace hex in Perl win32 by BrowserUk (Patriarch) on Sep 29, 2010 at 22:14 UTC
As I understand it, unless he explicitly removed the `:crlf` layer from `*ARGV`, then the IO layer will deal with the linefeeds and readline will never see them. Ie. "\n" has the same effective meaning on both platforms. But, if the file contains EBCDIC, then it might not contain anything that looks like a "normal" line ending at all. It's been too long since I worked with EBCDIC and I cannot remember what the equivalent byte code was. Nor even if it had one. It still doesn't explain why the code ran so fast on Linux. But, there are known cases with the default Windows memory allocator that can, under some thankfully rare, circumstances, display pathological behaviour.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Slow find/replace hex in Perl win32
by BrowserUk (Patriarch) on Sep 29, 2010 at 22:14 UTC

As I understand it, unless he explicitly removed the :crlf layer from *ARGV, then the IO layer will deal with the linefeeds and readline will never see them. Ie. "\n" has the same effective meaning on both platforms.

But, if the file contains EBCDIC, then it might not contain anything that looks like a "normal" line ending at all. It's been too long since I worked with EBCDIC and I cannot remember what the equivalent byte code was. Nor even if it had one.

It still doesn't explain why the code ran so fast on Linux. But, there are known cases with the default Windows memory allocator that can, under some thankfully rare, circumstances, display pathological behaviour.

[reply]
[d/l]
[select]