Open fsoft72 opened 1 year ago
Slightly better script.dart:
import "dart:convert";
void main() {
final List<int> list = List<int>.generate(
10000000,
(final int i) => i,
growable: false,
);
final Stopwatch watch = Stopwatch()..start();
const JsonEncoder().convert(list);
watch.stop();
print("Dart time: ${watch.elapsedMilliseconds} ms");
}
this script is took, 1172 ms
plus minus 2,
run with the command dart compile aot-snapshot drt.dart && dartaotruntime drt.aot
, thrice,
on intel-amd64-11gen, with dart-stable-2.19
Could dart be a good backend option in the future? Or do you think it will be killed by google?
Related: dart/sdk/issues/51596,
Could dart be a good backend option in the future? Or do you think it will be killed by google?
We have come too far, 99.9...% it won't be killed,
And the API is being optimized, with each release, by the dart's hard working team, for example this issue, once completed, would make socket reads, around 25 to 40 % faster,
But I think
io_uring
would be a much better choice now, asepoll
would not be the prime focus of the linux's net-workers, due to its in-efficient and patchy designCould dart be a good backend option in the future? Or do you think it will be killed by google?
We have come too far, 99.9...% it won't be killed,
And the API is being optimized, with each release, by the dart's hard working team, for example this issue, once completed, would make socket reads, around 25 to 40 % faster,
But I think
io_uring
would be a much better choice now, asepoll
would not be the prime focus of the linux's net-workers, due to its in-efficient and patchy design
So, can we think that Dart will have an important position on the server side in the future? Of course, I don't think it will be a competitor to Node js right away, but the current serverpod or shelf is not enough.
"will" is not correct, I think. the time is now,
The optimizations, and usage, go hand-in-hand,
Just the community is sleeping,
Once they wake up, and report their findings, and needs, like this issue.
Then the spark will become fire, which will just burn the JavaScript, NodeJS, React(-Native), KotlinMultiPlatform, and company...
"will" is not correct, I think. the time is now,
The optimizations, and usage, go hand-in-hand,
Just the community is sleeping,
Once they wake up, and report their findings, and needs, like this issue.
Then the spark will become fire, which will just burn the JavaScript, NodeJS, React(-Native), KotlinMultiPlatform, and company...
Unfortunately the community only cares about flutter. But at least I expect a significant improvement after Dart 3.
@regenin
So, can we think that Dart will have an important position on the server side in the future? Of course, I don't think it will be a competitor to Node js right away, but the current serverpod or shelf is not enough.
I think it could be a serious competitor to Node.js. The environment of JavaScript is changed a lot: in the early days, you used to write 'plain' javascript and have it served using node.js. Now, since the application complexity grew a lot, you can't rely on JS itself but everyone is moving to Typescript. Having a transpiler to your code, basically means you are compiling your code... so what would be the difference between "compiling" typescript to js and dart to exe? Without considering the npm hell that is becoming a real serious problem in these days (you can easily have 300/400 MB of javascript code in your node_modules directory without even knowing it).
Dart has many advantages over Typescript: the syntax is much clean, types are native to the language and so it is OOP... but to become a real competitor to the Node.js environments, Dart has to be really fast, or the community will stick to node.js for the server side anyway. At least, it has to become fast in the "common" functions / applications... and reading / writing JSON structures is the real fundamentals of any REST application.
This is most likely caused by us going num -> String -> Sink
route and then concatenating all strings together instead of simply formatting numbers into the buffer, which is what V8 is likely doing. We can optimise it by rewriting our JSON serialiser. I notice that _JsonUtf8Stringifier
seems to be doing the same suboptimal thing. (/cc @aam @lrhn)
Not that it really matters unless you want to serialise large amount of data (at which point you probably should not be using JSON in the first place).
FWIW alfred
should also do this add(JsonUtf8Encoder().convert(json))
instead of this write(jsonEncode(json))
here because that will fuse JSON serialisation and UTF8 conversion. (Though it probably will not immediately fix the performance difference because _JsonUtf8Stringifier
does not write numbers directly into the output buffer.
(I have marked most of the server-side Dart discussion as off topic for this issue, and respectfully encourage to continue it through other community channels).
I'd love to have an int writeInt(int value, List<int> bytes, [int start = 0, int end?])
which writes the string representation of an int
into a byte buffer, if there is room, and returns the end index.
And int parseInt(List<int> source, [int start = 0, int end?])
which parses the same way.
Since digits are ASCII, you can then directly parse from/write to an UTF-8 encoded byte sequence.
Let's see if we can find somewhere to add that. (Still need parsing to/from strings too, for all the usual uses, but avoiding going through strings when not necessary can be more performant.)
I am testing Dart capabilities as a web server and I am doing some easy tests against Node.js
I have written a simple program using the Alfred web server and I stumbled upon this issue:
dart.convert
/jsonEncode()
is slower than the Node.js counterpart.This is the Dart code of my server, it simply gets a
num
parameter and generates a list ofint
s with the number. In the end, it returns a JSON. The Alfred library callsdart.convert
/jsonEncode
on it.This is the server code (Node.js version is exactly the same, only using ExpressJS):
These are some tests I have run on both servers using restest NOTE: Dart version is an executable compiled with
dart compile exe
command.Node.js version
Dart version
As you can see, from second request and beyond the Node.js version is faster than the compiled Dart version. Everything is related to
jsonEncode()
, because if I change the server code, removing the list to be encoded in this way:The Dart version becomes the fastest, as you can see from these benchmarks:
Node.js version
Dart version
Dart SDK version: 2.19.3 (stable) (Tue Feb 28 15:52:19 2023 +0000) on "linux_x64"
I am attaching two very simple scripts (one for Dart and one for Node.js) that do not require any dependency, the Dart one is like this:
Node.js version executes in: 246 ms Dart version executes in: 615 ms
count.tar.gz