Re: Release vibe.d 0.7.27
Am 11.02.2016 um 00:24 schrieb sigod: Did some benchmarks between `std.net.curl.get` and `vibe.http.client.requestHTTP`. Only GET requests. 100 requests, ~1.4mb file: curl total: 131304, average: 1 sec and 313 ms vibe total: 21975, average: 219 ms 52 different files: curl total: 24851, average: 477 ms vibe total: 11290, average: 217 ms 50 different files (excluded 2 of the biggest ones): curl total: 20892, average: 417 ms vibe total: 11368, average: 227 ms (Looks like `std.net.curl.get` doesn't like if file is bigger than ~1mb.) Is vibe.d's API really that fast? Or am I doing something wrong? How fast was the network connection in that case? Could it make a difference if keep-alive connections are used or not? Were the requests done in parallel or in sequence? I certainly wouldn't expect curl to be slower for a simple sequential transfer of a single file, but who knows.
Re: Ddb needs a maintainer
On 2016-02-14 00:32, Dicebot wrote: Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly async API but I don't know if this is possible with ddbc design. It looks like libpg has support for asynchronous calls [1] but ddbc does not use them. Also, although libpg provides asynchronous calls I'm not sure if that automatically means it will be compatible with the IO model used by vibe. It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. I like that ddb is completely written in D and doesn't depend on any C libraries. It's also compatible with the IO model of vibe. Ideally a database library would consist separate projects for the different database drivers. These would be fully usable on their own. The database library would build a database independent layer on top of the drivers. Everything should be compatible with the IO model of vibe. I would go with ddb and mysql-native for the drivers. [1] http://www.postgresql.org/docs/current/static/libpq-async.html -- /Jacob Carlborg
Re: Ddb needs a maintainer
On 2016-02-13 14:11, Eugene Wissner wrote: Indeed. I have a fresh organization where I maintain D code: https://github.com/caraus-ecms. I could move it there and add pszturmaj to the organization. I don't see anything with the things you don't like about vibe.d going against vibe.d. It's just the default settings/choices that don't match what you want/need. "vibe.d is a framework to develop servers, network applications, it isn't really something you would usually use to develop a simple webpage or a blog or a forum." There are some abstractions on top of vibe.d [1] [2]. "I don't like Diet-Jade templates. I prefer templating engines like Mustache or Smarty." There are several Mustache packages for available through Dub [3] [4] [5]. "I don't like the choice of databases. Ok, I actually could write a driver for another database... I would go for PostgreSQL for the first time and it is still unsupported by default." Ddb, you already know about that one. "I want to learn D. PHP or Java may have too many frameworks, but it is still good to have a few of them, so people can choose what they like more." If you don't like any of the packages you can write your own on top of vibe.d. What I mean is that you don't need to start from scratch and write a completely new web framework. [1] http://code.dlang.org/packages/action-pack [2] http://code.dlang.org/packages/zeal [3] http://code.dlang.org/packages/semitwistweb [4] http://code.dlang.org/packages/mustache-d [5] http://code.dlang.org/packages/jax -- /Jacob Carlborg
Re: Ddb needs a maintainer
Ideally a database library would consist separate projects for the different database drivers. These would be fully usable on their own. The database library would build a database independent layer on top of the drivers. Everything should be compatible with the IO model of vibe. +1. It would be really great. Does anybody know something about dpq2? It doesn't use C-interface directly, but uses libpq's shared library (.so, .dll or .lib). It claims to support async queries and is most actively maintained in this time as I see. And it cares only about PostgreSQL.
Re: Ddb needs a maintainer
Am 14.02.2016 um 13:01 schrieb Jacob Carlborg: On 2016-02-13 14:11, Eugene Wissner wrote: Indeed. I have a fresh organization where I maintain D code: https://github.com/caraus-ecms. I could move it there and add pszturmaj to the organization. I don't see anything with the things you don't like about vibe.d going against vibe.d. It's just the default settings/choices that don't match what you want/need. "vibe.d is a framework to develop servers, network applications, it isn't really something you would usually use to develop a simple webpage or a blog or a forum." There are some abstractions on top of vibe.d [1] [2]. The approach of the vibe.web package is also already very similar to that IndexController mentioned in the other post.
Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 19:06:46 UTC, Eugene Wissner
wrote:
On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:
Hey Eugene,
Caraus seems like an interesting project. How do you plan to
build it out and differentiate it from vibe.d?
Difficult to explain it in a few sentences in a foreign
language, but I'll try. Just don't hesitate to ask if you have
any questions. I'm also not very familiar with vibe.d, I've
just seen a few examples and read about it a bit; so Sönke
should excuse or correct me if I say nonsense :).
It should be a framework for easy building and maintaining of
websites. The applications built on it would follow MVC (or
MVC-like) pattern by default, but since the framework is
thought as a set of reusable components/modules it should be
possible to use it for everything else like micro-webframework
for small projects with custom structure. The whole framework
should ship an abstraction over HTTP(S), mail sending
(sendmail, smtp), session handling with a possibility to
implement an own storage (file system, redis, memcached,
PostgreSQL...), dependency injection, router and so on.
It is a very common description. Now I make a few examples
showing what I think the framework should be able to do.
1) Creating a website should be as simple as creating a
Controller and a router configuration (YAML or database for
example), that assigns some route to this controller. Think of
something like this:
class IndexController
{
indexAction(Request request)
{
int contentId =
this.getDatabase().getContentModel().getPageById(5);
this.render("myTemplate.tpl", ["content": contentId]);
}
}
2) Form handling. You create a register form. So you create a
class User:
class User
{
int username;
string password;
}
and that class with some additional information should be
rendered to a web form. There are should be also routins to
help to verify the form (helpers for checking for email, length
of the input, phone number) and persist it to a database.
Whereby I don't think on ORM here, I'm not a big fan of ORMs.
For my projects I would implement a rich domain model with
domain objects, mappers... But it should be possible to use ORM
as well if this is available. Dependency Injection would make
such freedom possible. Btw. I think I won't write a DIc,
https://github.com/mbierlee/poodinis looks very promissing for
me. I would use any tools that meet requirements.
So it should help web developers in their daily job and should
make the web development pleasant.
It doesn't mean that I implement 10 session handlers from the
beginning. I will slowly implement things that I need for my
projects and will accept contributions if there are some
contributers one day.
And I can't promise that everything will be ready tomorrow. It
is very time consuming. But I got a new project last week that
may grow in the future. So I will begin to use these tools for
my work (I'm pretty free what I'm writing in and how I do it).
It can overlap with vibe.d here and there, but I think it is
more a continuation of vibe.d's http submodule. There were
already few attempts to create a similar framework on top of
vibe.d, see: https://github.com/CarbonComputed/carb.d or
https://github.com/Skadi-d/Skadi.d for example. But I want to
make it independent of the underlying platform (vibe.d, SCGI,
FastCGI).
So far
my five cents on that topic...
@Eugene:
From my point of view, it would be great if you could bring in
all your ideas, wishes, changes, additions and new stuff into
vibe_d and help to grow and extend it and make it more usable...
Don't get me wrong, I thinks it's great if developers have
various choices in general to pick from, but especially in Dlang
"core tools" some of the existing stuff needs more
contributors/help... like vibe_d, dub (both from Sönke & team)
dfmt, ...
You and Sönke share the same native language (German) and also
the same time zone (Munich/Berlin)... and as it seems also the
same interest in "Web stuff/Frameworks", right? It shouldn't be
that difficult for you guys to alighn and team-up to build an
even better "Dlang Web tools/Framework development team"...
Re: Ddb needs a maintainer
my five cents on that topic... @Eugene: From my point of view, it would be great if you could bring in all your ideas, wishes, changes, additions and new stuff into vibe_d and help to grow and extend it and make it more usable... Don't get me wrong, I thinks it's great if developers have various choices in general to pick from, but especially in Dlang "core tools" some of the existing stuff needs more contributors/help... like vibe_d, dub (both from Sönke & team) dfmt, ... You and Sönke share the same native language (German) and also the same time zone (Munich/Berlin)... and as it seems also the same interest in "Web stuff/Frameworks", right? It shouldn't be that difficult for you guys to alighn and team-up to build an even better "Dlang Web tools/Framework development team"... My native language is Russian, but my German is anyway better than my English, it's true :) Yes, I actually understand your point. I thought about it already and it could be really more productive. I think I have to look in vibe more closely. Maybe I'll just look into open issues on github, maybe I'll be able to find a few easy issues, I could try to fix - it could be the best way for me to get know vibe.d internally better.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Saturday, 13 February 2016 at 12:41:35 UTC, Daniel Murphy
wrote:
On 9/02/2016 12:23 AM, Atila Neves wrote:
What's new:
Built-in unittest blocks can now have a name with just a
string UDA:
@("test that does stuff") unittest {... }
I feel obliged to point out that this is going to be a disaster
as soon as any other library decides that means something else.
The @Name UDA still exists, and I think it's unlikely another
library will be looking for string UDAs on unittest blocks that
isn't itself a testing library.
Atila
Re: Ddb needs a maintainer
On 2016-02-14 12:48, Jacob Carlborg wrote: It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example. Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you?
LDC 0.17.0 has been released!
Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Don't miss to check if your preferred system is supported by this release. We also have a Win64 compiler and PREVIEW of a Win32 compiler available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org Regards, Kai
Re: DigitalWhip
On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Hi Artem, On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: https://github.com/artemalive/DigitalWhip Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test: --- Compiler relative times: clang 1.00 gcc 1.02 ldc 1.07 dmd 2.07 --- — David Hi David, I use -release option. It seems no need to disable bounds check explicitly. From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;)
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. Specific parts of the code might disable it via `.ptr`, but the command line switch is dangerous and I can't recommend anyone to use it... ever. We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C, but we'll be the ones laughing when the C program crashes with yet another buffer overrun or when it's milliseconds in execution time lead to days of debug time and a multi-million dollar business loss when an unchecked pointer leads to a security breech. Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. Nevertheless, I have to admit I'm still on the dark side. Benchmark has some algorithms related to raytracing techniques and in this area I can't resist temptation to max performance at any cost.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote: Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. If you do, then you should use bounds checks in C++ too. (STL container.at(index) )
Re: DigitalWhip
On Saturday, 13 February 2016 at 19:26:39 UTC, artemalive wrote: On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote: Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it) These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2. What I meant to say is that the framework should output the compiler version, instead of "READY". At least for the D compilers, the performance depends so much on which version is used, that the output is unusable without version numbers, I feel.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:43:01 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote: Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. If you do, then you should use bounds checks in C++ too. (STL container.at(index) ) Thanks, I'll take this into account. At the moment I don't think bounds checking will be enabled. I believe that real world usage when you have a render farm is to have the fastest code possible, because any performance penalty is too costly. When new rendering algorithm is developed sometimes we run infinite rendering with all debug/logic check enabled to find the bugs. There could be even dedicated computer for this. But for production when thousands of cores do the same ray processing the fastest code is needed.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:49:10 UTC, Johan Engelen wrote: On Saturday, 13 February 2016 at 19:26:39 UTC, artemalive wrote: On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote: Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it) These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2. What I meant to say is that the framework should output the compiler version, instead of "READY". At least for the D compilers, the performance depends so much on which version is used, that the output is unusable without version numbers, I feel. Thanks. Good suggestion. I'll check if the version information can be retrieved automatically for all compilers. If that's the case then version information will be added soon. The thing I don't want to do is to ask user manually to specify compiler version in config.py, since it's easy to forget to updated it and also I like to keep config.py as simple as possible. At the moment DigitalWhip is just for personal usage, the user knows which compilers are installed. But version information will help with archiving/sharing results.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:31:37 UTC, artemalive wrote: From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". We (LDC team) should clarify this description. In D2, -release does not disable bounds-checking for @safe code anymore. -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;) I'm not convinced that it makes for a good comparison to use different optimization settings for one of the compilers… — David
Re: DigitalWhip
On Sunday, 14 February 2016 at 18:12:03 UTC, David Nadlinger wrote: On Sunday, 14 February 2016 at 17:31:37 UTC, artemalive wrote: From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". We (LDC team) should clarify this description. In D2, -release does not disable bounds-checking for @safe code anymore. -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;) I'm not convinced that it makes for a good comparison to use different optimization settings for one of the compilers… — David Sure, we need the same optimization for all compilers if there is direct correspondence. Your pull request has been merged.
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. I agree - but not for all situations. Sometimes it's fine to let programs crash, if performance is important, and the environment is configured to handle that gracefully, or where there is no risk of data loss, such as video games. I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits.
Re: Ddb needs a maintainer
On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote: On 2016-02-14 12:48, Jacob Carlborg wrote: It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example. Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you? yes, it is for sure ok for me. It can be a good start. I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it.
Re: Ddb needs a maintainer
On Sunday, 14 February 2016 at 19:48:34 UTC, Eugene Wissner wrote: On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote: On 2016-02-14 12:48, Jacob Carlborg wrote: It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example. Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you? yes, it is for sure ok for me. It can be a good start. I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it. I like idea to have one good driver instead of two of not finished, and would like that it ships as vibe-d module. For my regret I have not enough so experience to help with developing. But if you will decide to collaborate with ddbc developer (he is also russian-speaker) it will be very cool.
Re: Ddb needs a maintainer
On Sun, 14 Feb 2016 12:48:49 +0100, Jacob Carlborg wrote: > On 2016-02-14 00:32, Dicebot wrote: > >> Ideally ddb should be built on top of ddbc wrapping it into >> fiber-friendly async API but I don't know if this is possible with ddbc >> design. > > It looks like libpg has support for asynchronous calls [1] but ddbc does > not use them. Also, although libpg provides asynchronous calls I'm not > sure if that automatically means it will be compatible with the IO model > used by vibe. If you have asynchronous calls that you can poll, you can make it work with vibe.d, albeit awkwardly. (Start request, poll+yield, return when there's a result.) If you only have synchronous calls, you'd have to introduce IO threads and synchronization. It's awkward to make things compatible with vibe.d and Phobos IO. The APIs are rather dissimilar, so you can't just, for instance, have different imports under a version() block.
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 17:30:33 UTC, Kai Nacke wrote: Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Don't miss to check if your preferred system is supported by this release. We also have a Win64 compiler and PREVIEW of a Win32 compiler available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org Regards, Kai Congrats! Awesome that Win32 received work. The Windows versions worked out of the box this time.
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 17:30:33 UTC, Kai Nacke wrote: Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Regards, Kai congrats! what is actually the difference on wheter i build with LLVM 3.5 or 3.8? in other words, what influence does the ldc version have?
Re: LDC 0.17.0 has been released!
On 02/14/2016 07:30 PM, Kai Nacke wrote: > As usual, you can find links to the changelog and the binary packages > over at digitalmars.D.ldc: > http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org https://www.archlinux.org/packages/community/x86_64/ldc https://www.archlinux.org/packages/community/i686/ldc
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 20:55:14 UTC, y wrote: what is actually the difference on wheter i build with LLVM 3.5 or 3.8? in other words, what influence does the ldc version have? This really depends on your target. For x86_64 the biggest difference is auto-vectorization with avx/avx2 which is better in later LLVM versions. The non-X86 are usually more mature in later LLVM versions. E.g. for MIPS64 you should at least use LLVM 3.7. Put into a simple rule: - For X86 there is no big difference - For non-X86 use the latest LLVM version Regards, Kai
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 20:55:40 UTC, Dicebot wrote: On 02/14/2016 07:30 PM, Kai Nacke wrote: As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org https://www.archlinux.org/packages/community/x86_64/ldc https://www.archlinux.org/packages/community/i686/ldc Thanks!
Re: DigitalWhip
On Sunday, 14 February 2016 at 19:29:54 UTC, Vladimir Panteleev wrote: I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits. But nobody would write a render-engine in Go. Most likely you would write it for GPU support and certainly use SIMD heavily. That's what current engines do. So if it is a benchmark, then it makes perfect sense to use the same feature set for all languages. But optimization should be set to the highest possible, including whole program optimization where available. It's a benchmark...
Re: DigitalWhip
On Sunday, 14 February 2016 at 18:07:00 UTC, artemalive wrote: Thanks. Good suggestion. I'll check if the version information can be retrieved automatically for all compilers. If that's the case then version information will be added soon. I would simply print the output of "--version" for all compilers. But version information will help with archiving/sharing results. Exactly.
Re: Release vibe.d 0.7.27
On Sunday, 14 February 2016 at 08:17:34 UTC, Sönke Ludwig wrote: Am 11.02.2016 um 00:24 schrieb sigod: Did some benchmarks between `std.net.curl.get` and `vibe.http.client.requestHTTP`. Only GET requests. 100 requests, ~1.4mb file: curl total: 131304, average: 1 sec and 313 ms vibe total: 21975, average: 219 ms 52 different files: curl total: 24851, average: 477 ms vibe total: 11290, average: 217 ms 50 different files (excluded 2 of the biggest ones): curl total: 20892, average: 417 ms vibe total: 11368, average: 227 ms (Looks like `std.net.curl.get` doesn't like if file is bigger than ~1mb.) Is vibe.d's API really that fast? Or am I doing something wrong? How fast was the network connection in that case? Could it make a difference if keep-alive connections are used or not? Were the requests done in parallel or in sequence? I certainly wouldn't expect curl to be slower for a simple sequential transfer of a single file, but who knows. https://gist.github.com/sigod/c78c61ac6118fa9fda26 I'm getting something like this: HTTPS: curl total: 23401, average: 458ms vibe total: 12136, average: 237ms HTTP: curl total: 5577, average: 278ms vibe total: 4268, average: 213ms Windows 7 x86, dmd 2.070.0
