[PR #1974] [CLOSED] Removal of smallvec from dependancies. #2731

New issue

Closed

opened 2026-03-16 11:05:12 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:05:12 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/1974
Author: @darnuria
Created: 6/20/2023
Status: ❌ Closed

Base: main ← Head: remove/smallvec

📝 Commits (1)

a5b088e Removal of smallvec from depenancies.

📊 Changes

8 files changed (+5 additions, -11 deletions)

View changed files

📝 Cargo.lock (+0 -2)
📝 Cargo.toml (+0 -1)
📝 crates/proto/Cargo.toml (+0 -1)
📝 crates/proto/src/serialize/binary/encoder.rs (+1 -1)
📝 crates/proto/src/xfer/dns_request.rs (+1 -1)
📝 crates/resolver/Cargo.toml (+0 -1)
📝 crates/resolver/src/config.rs (+1 -1)
📝 crates/resolver/src/name_server/name_server_pool.rs (+2 -3)

📄 Description

Hello, taking interrest with issue: https://github.com/bluejekyll/trust-dns/issues/365

Disclamer: the approach is naive I know it involve a most to malloc and leaved the code untouched even allocating in a loop, mostly to began exploring the subject! :)

In crate/resolver I chosed to use a plain vec since the type: SmallVec::<[Nameservers; 2] reached 544 bytes not sure it's small anymore. (did a little std::mem::size_of::<SmallVec<[NameServer;2]>>() to get the size in bytes)

Why I didn't used TinyVec directly? Because it would have needed a Default implementation on each types of Nameservers.

If it's not the best course of action I am ok to get some mentoring! :)

Some idea I have in mind:

If it's not the right course of action: either close #365, or reformulate it and document here why smallVec is mandatory here.
If it's OK but need tinyVec, will need some work since Default is mandator due to TinyVec Array trait.
If the plain Vec is good enough then just have something less naive ! ;)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/1974 **Author:** [@darnuria](https://github.com/darnuria) **Created:** 6/20/2023 **Status:** ❌ Closed **Base:** `main` ← **Head:** `remove/smallvec` --- ### 📝 Commits (1) - [`a5b088e`](https://github.com/hickory-dns/hickory-dns/commit/a5b088ee18bbefdff3a6074af1f938c68bed1e03) Removal of smallvec from depenancies. ### 📊 Changes **8 files changed** (+5 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+0 -2) 📝 `Cargo.toml` (+0 -1) 📝 `crates/proto/Cargo.toml` (+0 -1) 📝 `crates/proto/src/serialize/binary/encoder.rs` (+1 -1) 📝 `crates/proto/src/xfer/dns_request.rs` (+1 -1) 📝 `crates/resolver/Cargo.toml` (+0 -1) 📝 `crates/resolver/src/config.rs` (+1 -1) 📝 `crates/resolver/src/name_server/name_server_pool.rs` (+2 -3) </details> ### 📄 Description Hello, taking interrest with issue: https://github.com/bluejekyll/trust-dns/issues/365 Disclamer: the approach is naive I know it involve a most to malloc and leaved the code untouched even allocating in a loop, mostly to began exploring the subject! :) In crate/resolver I chosed to use a plain vec since the type: `SmallVec::<[Nameservers; 2]` reached 544 bytes not sure it's small anymore. (did a little `std::mem::size_of::<SmallVec<[NameServer;2]>>()` to get the size in bytes) Why I didn't used TinyVec directly? Because it would have needed a `Default` implementation on each types of `Nameservers`. If it's not the best course of action I am ok to get some mentoring! :) Some idea I have in mind: * If it's not the right course of action: either close #365, or reformulate it and document here why `smallVec` is mandatory here. * If it's OK but need tinyVec, will need some work since `Default` is mandator due to `TinyVec` `Array` trait. * If the plain Vec is good enough then just have something less naive ! ;) --- 🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.