A room for miscellaneous Dart-related discussions. (More rooms: gitter.im/dart-lang/home)
nyxx using null safety and dependencies not fully supporting it, dart --enable-experiment=non-nullable --no-null-safety .\bin\main.dart will supress the issues in libraries, but for whatever reason only works on dart 2.9 or lower, 2.10 doesn't support this feature??
Today I released the first version of my package babylon_dart. It contains bindings to BabylonJS for the Dart language.
It is work in progress. Issues for feature request are welcome. Pull request even more.
Hi all!
I have a dart performance design/architecture question, which I realize may not have a simple answer.
I'm working on a Git implementation in Dart, that needs to be fast, as I'm going to use it to run a database stored as a git repository.
Most of the IO load will be thousands of small read operations across one or more files.
CPU load will consist of decompressing the data, and concatenating small chunks into larger UInt8Lists (still mostly less than 1KByte)
Some of these operations may be parallellizable (decompression, processing of unrelated objects).
Some processing could happen while waiting for IO.
My dilemma is as follows..
Should I implement "everything" (including all low level IO operations, and cpu limited operations) with async/await?
Will this give me a performance boost or make it easier to parallelize things in the future?
Or will there be a significant overhead cost, and should I rather make most low-level operations Synchronous, and parallelize on a high level with Isolates where possible?
I noticed as many people point out that 'async' is contagious, and slowly all my functions now have 'async' in the name, so it will be costly to make everything sync again later.
Thats why I want to make an informed decision at this point.
Any thoughts?
thanks for your reactions and suggestions. if the question is clear enough and 'answerable' in its current form, then i could post it on SO indeed. I wasn't sure that it was.
@bpilot yes, git uses Zlib, and I'm currently using the dart:convert library to decode the streams.
https://stackoverflow.com/questions/63927682/dart-performance-best-approach-for-thousands-of-low-level-io-operations
:-D
But I thought I could avoid doing that if some more experienced folks could point me in the right direction earlier on
Considering all of that, you are not worse off to implement it with async, and it is more reuse- and future-friendly, especially if the app wanted to serve many requests.
sounds like async is the way to go then. for very small operations like reading a single byte, i could go sync, which would be a trivial code change, and even that I can postpone until a benchmark shows that its a bottle neck.
for this package to be more accessible, I would recommend to provide some small example code, so its easy to see what functionality the package provides
Object 's interface, such as toString , operator== and hashCode. Is there any better way? I was thinking of something along the lines of Data Classes in Kotlin: https://kotlinlang.org/docs/reference/data-classes.html
Stream<int> getStream() async {
final object = await getObject();
return object.dataStream;
}
// functions marked async must return Futurethe only reason i can't do that is that I need to
await :-S
@boukeversteegh You can use yield*, which is easier to read (and more efficient I think):
Stream<int> getStream() async* {
final object = await getObject();
yield* object.dataStream;
}If you want to avoid the overhead of async* entirely, you could also use
Stream<int> getStream() {
return Stream.fromFuture(getObject()).asyncExpand((obj) => obj.dataStream);
}
package:async. https://pub.dev/documentation/async/latest/async/StreamCompleter/fromFuture.htmlFuture<String<int>> _someData() async {
final object = await someObject();
return object.dataStream;
}
Stream<int> someData() => StreamCompleter.fromFuture(_someData());
Hello friends, I created a cli to help manage dependencies in a Dart/Flutter project. I'm keen to get some thoughts on this one :)
Here's the jist of how the tool works:
$ crawl init # launch pubspec.yaml creation wizard
$ crawl install -p <pkg> # add a package to dependencies section
$ crawl install -p <pkg> -d # add a package to dev_dependencies sectionMore details here: https://pub.dev/packages/crawl
4 replies
@gmpassos My first impressions: dependency_scanner looks similar although its concern is Dart projects while I'm focused on Dart packages.
@simolus3 Looks good, can't wait to have pub add and pub remove. Meanwhile crawl is ok for use now and will be adding a couple more commands so that it's not just adding and removing packages.
@boukeversteegh Hadn't thought of that 🤔 Now that I know pub uses args package I'll consider it.
adding the library as content-root in the IDE made the coverage show up!