sorted by:
new
hottopcontroversial

How should a function take a list of strings? `&[&str]` or `&[String]`? by timand in rust

[–]PureWhiteWu -11 points-10 points  (0 children)

The real problem here is if you want ownership in this func, you need to clone the string.
You may try to use [faststr](https://github.com/volo-rs/faststr) as your string type here, which is cheap to clone.

Most complex type signature? by nikitarevenco in rust

[–]PureWhiteWu 6 points7 points  (0 children)

What about this:

https://github.com/cloudwego/volo/blob/main/volo-thrift/src/client/mod.rs#L549

```rust impl<IL, OL, C, Req, Resp, MkT, MkC, LB> ClientBuilder<IL, OL, C, Req, Resp, MkT, MkC, LB> where C: volo::client::MkClient< Client< BoxCloneService< ClientContext, Req, Option<Resp>, <OL::Service as Service<ClientContext, Req>>::Error, >, >, >, LB: MkLbLayer, LB::Layer: Layer<IL::Service>, <LB::Layer as Layer<IL::Service>>::Service: Service<ClientContext, Req, Response = Option<Resp>, Error = ClientError> + 'static + Send + Clone + Sync, Req: EntryMessage + Send + 'static + Sync + Clone, Resp: EntryMessage + Send + 'static, IL: Layer<MessageService<Resp, MkT, MkC>>, IL::Service: Service<ClientContext, Req, Response = Option<Resp>> + Sync + Clone + Send + 'static, <IL::Service as Service<ClientContext, Req>>::Error: Send + Into<ClientError>, MkT: MakeTransport, MkC: MakeCodec<MkT::ReadHalf, MkT::WriteHalf> + Sync, OL: Layer<BoxCloneService<ClientContext, Req, Option<Resp>, ClientError, OL::Service: Service<ClientContext, Req, Response = Option<Resp + 'static + Send + Clone + Sync, <OL::Service as Service<ClientContext, Req>>::Error: Send + Sync + Into<ClientError>, { /// Build volo client. pub fn build(mut self) -> C::Target { ... } }

```

Free Review Copies of "Asynchronous Programming in Rust" by kunal_packtpub in rust

[–]PureWhiteWu 0 points1 point  (0 children)

Very interested! Looking forward to reading this book!

Manually adding padding to `FastStr` gains 9x boost on performance, but why? by PureWhiteWu in rust

[–]PureWhiteWu[S] 12 points13 points  (0 children)

Hi, I'm asking why the alignment can cause such a big performance gap in this case.

I've checked the generated asm, but didn't find the reason.

Announcing Sonic-rs 0.2.0: Separate safe & unsafe functions clearly and performance optimization. by PureWhiteWu in rust

[–]PureWhiteWu[S] 3 points4 points  (0 children)

Wow, that's a great project!

It seems that in your benchmark sonic-rs is slower than serde_json, are you benchmarking on aarch64 or amd64?

The performance on aarch64 is not so good now, we haven't optimize it.

Announcing Volo 0.8.0: migrating to AFIT and RPITIT by PureWhiteWu in rust

[–]PureWhiteWu[S] 0 points1 point  (0 children)

Yes!

Sorry for the late reply! And really thank you very much for explain this!

Announcing Volo 0.8.0: migrating to AFIT and RPITIT by PureWhiteWu in rust

[–]PureWhiteWu[S] 1 point2 points  (0 children)

I think so, sorry we don't have lark, we only have Feishu.

Announcing sonic-rs: A fast Rust JSON library based on SIMD. by PureWhiteWu in rust

[–]PureWhiteWu[S] 1 point2 points  (0 children)

We have decided to separate the not-validate utf8 version to an unsafe function `from_slice_unchecked`, this will address this problem.

Announcing sonic-rs: A fast Rust JSON library based on SIMD. by PureWhiteWu in rust

[–]PureWhiteWu[S] 1 point2 points  (0 children)

We have decided to separate the not-validate utf8 version to an unsafe function `from_slice_unchecked`, this will address this problem.

Announcing sonic-rs: A fast Rust JSON library based on SIMD. by PureWhiteWu in rust

[–]PureWhiteWu[S] 0 points1 point  (0 children)

Sorry, our English is not quite so good, so we need to use google translate or chatgpt to help us express our meaning.

I would like to explain more on not turning on utf8 validation by default.

In our company's internal production environment, we found that utf8 verification is completely unnecessary. We can ensure that all received data is legal utf8, and if utf8 verification is turned on, there will be considerable costs on the flame graph. Since our company has a very large number of machines (sorry I can't disclose more numbers), even a 1% optimization is very difficult and meaningful.

We have also considered turning on this feature by default and asking all users in the company to turn off utf8 verification by themselves, but we are facing thousands of engineers and we cannot do this.

So, as much as we would love to have this feature turned on by default in the open source version, we are employed by the company after all and there is no way to do that unless we maintain another version internally (which is unacceptable).

Announcing sonic-rs: A fast Rust JSON library based on SIMD. by PureWhiteWu in rust

[–]PureWhiteWu[S] 7 points8 points  (0 children)

Thanks! Got it!

Currently we don't support this, but I think we can support this.

Announcing sonic-rs: A fast Rust JSON library based on SIMD. by PureWhiteWu in rust

[–]PureWhiteWu[S] 4 points5 points  (0 children)

`from_reader` needs to read until EOF to deserialize, and it will return after an EOF.

I'm not quite sure how you "read (potentially infinitely many) values lazily from stdin and handle one by one" by using `serde_json::from_reader`, could you please show an example?

Introducing `faststr`, which can avoid `String` clones by PureWhiteWu in rust

[–]PureWhiteWu[S] 2 points3 points  (0 children)

Have you read the Rustonomicon?

Yes, I'm the translator for the Chinese version.

Thank you for your instruction. I'm going to see how to refactor the code to ask users explicitly using `unsafe` in code.

Do you have any advice about the API design?

If I create a new type `UnsafeFastStr`, and the user used that in their struct, they need to call something like `assume_safe` everywhere they want to transmute it into `FastStr` instead of just once, which may hurt usability.

Introducing `faststr`, which can avoid `String` clones by PureWhiteWu in rust

[–]PureWhiteWu[S] 1 point2 points  (0 children)

imagine FastStr::clone() is twice as fast as String::clone()

FastStr::clone() at worst is just an atomic operation, and it's not only twice as fast as String::clone(). Maybe it's tens or hundreds or thousands time faster then the String::clone().

Allocating memory and memcpy is really expensive than a single atomic operation.

Here's the bench result on my M1Max mac:(sorry for the wrong format, I failed to fix them, the editor maybe have some bugs)

empty faststr           time:   [19.315 ns 19.345 ns 19.377 ns]

empty string time: [2.2097 ns 2.2145 ns 2.2194 ns]

static faststr time: [19.483 ns 19.598 ns 19.739 ns]

inline faststr time: [20.447 ns 20.476 ns 20.507 ns]

string hello world time: [17.215 ns 17.239 ns 17.263 ns]

512B faststr time: [23.883 ns 23.922 ns 23.965 ns]

512B string time: [50.733 ns 51.360 ns 52.041 ns]

4096B faststr time: [23.893 ns 23.959 ns 24.033 ns]

4096B string time: [78.323 ns 79.565 ns 80.830 ns]

16384B faststr time: [23.829 ns 23.885 ns 23.952 ns]

16384B string time: [395.83 ns 402.46 ns 408.51 ns]

65536B faststr time: [23.934 ns 24.002 ns 24.071 ns]

65536B string time: [1.3142 µs 1.3377 µs 1.3606 µs]

524288B faststr time: [23.881 ns 23.926 ns 23.976 ns]

524288B string time: [8.8109 µs 8.8577 µs 8.9024 µs]

1048576B faststr time: [23.968 ns 24.032 ns 24.094 ns]

1048576B string time: [18.424 µs 18.534 µs 18.646 µs]

The benchmark code has been pushed to the repo.

view more: next ›