-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Array.partition benchmarks (see #829) #830
Array.partition benchmarks (see #829) #830
Conversation
I updated the Array.partition code to include some of your optimizations over my implementation in gasche_partition. |
Having provided a benchmark is nice, however I don't like so much large chunks of code lying around. |
You can reopen if you super strongly disagree, though. |
(Personally I think that having benchmarks around is useful in case people want to work on optimizing the functions again, but you do as you prefer.) |
You have a point. |
If you know how the merge conflict should be resolved, I vote to merge it. PS: I hope those benchs are not always run when we compile batteries, I guess not |
Hi,
|
@gasche's version can also be improved a little bit the same way using a type let gasche_partition_s p xs =
let n = BatArray.length xs in
if n = 0 then ([||], [||]) else begin
let size_yes = ref 0 in
let _true = char_of_int 1 in
let _false = char_of_int 0 in
let bs = Bytes.init n (fun i ->
let b = p (BatArray.unsafe_get xs i) in
if b
then (incr size_yes; _true)
else _false) in
let yes = Array.make !size_yes xs.(0) in
let no = Array.make (n - !size_yes) xs.(0) in
let iyes = ref 0 in
let ino = ref 0 in
for i = 0 to n - 1 do
if (Bytes.unsafe_get bs i) = _true then begin
BatArray.unsafe_set yes !iyes (BatArray.unsafe_get xs i);
incr iyes;
end else begin
BatArray.unsafe_set no !ino (BatArray.unsafe_get xs i);
incr ino;
end
done;
yes, no
end pseudo-bench:
it will maybe also use less space. |
@fccm the time command, while useful to have a first idea, is not proper benchmarking. Cf. https://github.com/janestreet/core_bench/ or https://github.com/Chris00/ocaml-benchmark |
I agree with you, this is why I wrote "pseudo-bench", |
I didn't notice any performances difference between bytes and string, so using string is probably a better choice to stay backward compatible. |
Feeling I am living dangerously: I just resolved the conflicts using github's interface, on a PR which is not mine... |
cc: @UnixJunkie
Please try the benchmarks on your machine:
On my machine, they confirm that your implementation in #829 is faster. I would support merging both pull-requests.