Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Async Methods
See original GitHub issueKinda picking up off of https://github.com/elastacloud/parquet-dotnet/issues/20
I see now that the thrift lib ONLY has async methods, and the older clients are being removed next release.
I’m not sure how often parquet updates it’s thrift spec, or how often thrift adds new features or w/e though, so this might not be a big deal.
Curious if In the past have you done any testing to see what kind of negative performance making some of the reading/writing async has?
Was considering helping and trying to update to the latest netstd thrift generation, but I’m more interested in making this faster…not slower 😉
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
The issue is Thrift part plays a miniscule role on performance, and will actually slow down a bit. You want async in the core where data pages are read from disk.
Async won’t make it faster, but will make it more scalable. For I/O, async is definitely the way to go.
We had a lot of async enhancements in the recent releases of .NET Core, like performance and memory allocation improvements and new API’s. Do you have plans to drop support to old .NET versions and migrate to .NET 3.1/5?
Span<T> can also bring performance improvements, many new Async APIs uses Span to avoid copying memory