[m-rev.] for review: specialise file copying in the compiler

Zoltan Somogyi zoltan.somogyi at runbox.com
Sat Apr 23 21:51:36 AEST 2022


2022-04-23 21:38 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> Specialise file copying in the compiler.
> 
> Specialise the Mercury implementation of file copying in the compiler by
> avoiding the use of io.binary_input_stream_foldl_io/5. This allows us to avoid
> a higher-order call each time a byte is written and it allows us to use the
> unboxed version of the predicate that reads bytes. The other reason for this
> change is that we are planning to deprecate (and eventually remove)
> io.binary_input_stream_foldl_io/5.

Avoiding the use of binary_input_stream_foldl_io is a good idea,
and we have agreed on it a while ago. But copying the input one byte
at a time isn't the right approach. The right approach would be to
read the entire file to be copied into a buffer, and then write out the buffer.
You could then use stat to preallocate exactly the buffer size you need,
and read the entire file with one system call, at least for files that (a) have
a known size, unlike streams, and (b) have a size that fits into main memory.
The only reason I did not do that when eliminating the other uses of stream_foldl_io
in the compiler is that we don't yet have a byte_array type for the buffer.
We even had a conversation about what to name it, in both read-only
and read-write versions, a month or two ago. I thought, maybe mistakenly,
that you said you would implement those types. (I don't know Java and C#
well enough to do this for them, or I would do it myself.)

> library/io.m:
>     Refer to the Boolean constant yes/0 and no/0 in C code as MR_YES
>     and MR_NO respectively, rather than MR_TRUE and MR_FALSE.

That part is fine.

Zoltan.


More information about the reviews mailing list