[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?

From: Koichi Murase
Subject: Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?
Date: Sat, 8 May 2021 02:32:51 +0900

2021年5月5日(水) 6:18 Chet Ramey <chet.ramey@case.edu>:
> I used a combination of the simpler approach and the fstat/S_ISREG
> strategy you suggested in your previous email.

Thank you. I have tried the updated version of mapfile in 59c575fd.
Now it runs with temporary files as fast as the newline case.

$ a=({000000..500000})
$ time printf '%s\0' "${a[@]}" > tmp
$ time mapfile -d '' b < tmp

It is 1000--2500x faster than the other approaches using `source' or `eval':

$ time declare -p a > tmp
$ unset a; time source tmp
$ unset a; time eval "$(< tmp)"

> >> (3) Suggestion: change the order of `run_callback' and `zsyncfd'?
> >
> > [...]
> I don't think this will make much of a difference -- it never has,

I suspect it's because the buffered read was only enabled when delim
== '\n' before and read(2) has read exactly until the delimiter in
most cases. Now we have changed that condition, so I guessed we want
to be more careful.

> and the state of the file during the callback's execution isn't
> defined

That's true... which was the reason that I wrote "I feel it is better"
instead of "We should" in the suggestion email. I think the result
becomes well-defined (i.e., predictable) with the new ordering of
`zsyncfd' and then `run_callback'.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]