# \[ANN\] KWayMerges.jl: Small package for the k-way merge algorithm
**URL:** https://discourse.julialang.org/t/ann-kwaymerges-jl-small-package-for-the-k-way-merge-algorithm/130340
**Category:** Package Announcements
**Created:** [June 30, 2025, 6:45pm UTC](https://discourse.julialang.org/t/ann-kwaymerges-jl-small-package-for-the-k-way-merge-algorithm/130340 "2025-06-30T18:45:18Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)
#### Post date: [June 30, 2025, 6:45pm UTC](https://discourse.julialang.org/t/ann-kwaymerges-jl-small-package-for-the-k-way-merge-algorithm/130340/1 "2025-06-30T18:45:18Z")
I’m pleased to introduce the newest BioJulia package: [KWayMerges.jl](https://github.com/BioJulia/KWayMerges.jl) - currently [undergoing registration](https://github.com/JuliaRegistries/General/pull/133954).
This tiny package provides the `KWayMerger` type, which lazily merges multiple sorted iterators into a single, sorted stream. It’s generally faster than appending all the iterators and calling `sort!`.
For example:
```julia
julia> using KWayMerges
julia> vs = [[4,6], [7,9], [1,5]];
julia> [last(i) for i in KWayMerger(vs)]
6-element Vector{Int64}:
1
4
5
6
7
9
```
Currently, it’s implemented using a heap. The [Wikipedia article](https://en.wikipedia.org/wiki/K-way_merge_algorithm#) claims a tournament tree is faster, so soon-ish I’ll try re-implementing the `KWayMerger` using one of those and see if it’s faster. But for now, I just wanted something that I knew worked.
---
### Author:  [@digital\_carver](https://discourse.julialang.org/u/digital_carver)
#### Post date: [June 30, 2025, 11:08pm UTC](https://discourse.julialang.org/t/ann-kwaymerges-jl-small-package-for-the-k-way-merge-algorithm/130340/2 "2025-06-30T23:08:33Z")
This maybe a basic Julia question, but:
```julia
help?> KWayMerger
...
This iterator yields (index::Int, x::T) elements
```
Is there a reason (performance or otherwise) that it can’t yield `@NamedTuple{fromiter::Int, value::T}` elements instead? Remembering what the two tuple elements mean is a small thing in isolation, but can get pretty annoying and negatively affect readability when part of a large complex codebase. NamedTuples would still allow numeric-index-based and `first`/`last` access if preferred, but also allow nicer, more ergonomic access and display. I don’t know what the other side of the tradeoff is though, if any.
---
### Author:  [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)
#### Post date: [July 1, 2025, 11:52am UTC](https://discourse.julialang.org/t/ann-kwaymerges-jl-small-package-for-the-k-way-merge-algorithm/130340/3 "2025-07-01T11:52:00Z")
That’s a good idea. I should probably also add a sort-like API supporting `by`, `lt`, `rev` and `order`, if those are zero-cost.