digitalmars.D.announce - Release vibe.d 0.7.27
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (28/28) Feb 09 2016 This release brings some larger changes:
- extrawurst (3/12) Feb 09 2016 Awesome! Thanks for all the hard work.
- Nick B (4/18) Feb 09 2016 I look forward to reading the numbers, and seeing how it
- Dicebot (2/5) Feb 09 2016 Changelog looks very exciting, good work!
- Andrei Alexandrescu (2/6) Feb 09 2016 Congrats!! -- Andrei
- =?iso-8859-1?Q?Robert_M._M=FCnch?= (6/7) Feb 10 2016 Great stuff!! Thanks a lot for your engagement.
- Iain Buclaw via Digitalmars-d-announce (5/29) Feb 10 2016 Not a problem. We may be on 2.068 sooner than you think (I know that 2....
- Suliman (2/55) Feb 10 2016 Does your company use D?
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (3/6) Feb 10 2016 Really glad to hear that! BTW, is anything moving w.r.t. integrating GDC...
- Iain Buclaw via Digitalmars-d-announce (5/14) Feb 10 2016 Don't think so. We have Travis CI building DMD with GDC and LDC for eac...
- Daniel Kozak via Digitalmars-d-announce (2/34) Feb 10 2016 Wow, that would be awesome :)
- sigod (14/14) Feb 10 2016 Did some benchmarks between `std.net.curl.get` and
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (5/18) Feb 14 2016 How fast was the network connection in that case? Could it make a
- sigod (10/39) Feb 14 2016 https://gist.github.com/sigod/c78c61ac6118fa9fda26
This release brings some larger changes:
- The library has been split up into sub packages: code, utils, data,
http, mail, diet, mongodb, redis and web. This is an intermediate
step to moving the individual packages out to separate repositories
with independent version numbers.
- A lot of work went into performance tuning. Single-core performance
of the HTTP server is improved by about +50% and multi-core
performance scales properly again after excessive lock contention
sneaked in in one of the previous releases. The number of worker
threads is now also properly determined on all systems (including
multi-CPU), which should fix the numbers for multi-threaded
benchmarks (an update to the TechEmpower benchmark suite is on the
way).
- The REST interface generator now supports modelling collections with
native D syntax using Collection!T. It also adds support for CORS.
- The std.concurrency integration has been fixed and re-enabled - you
can now use std.concurrency without worrying about blocking the
event loop. In case of problems (std.concurrency doesn't support
passing certain kinds of values), the old implementation can still
be accessed as sendCompat/receiveCompat/...
- Compiles on 2.066.0 up to 2.070.0. Note that this will be the last
release that supports the 2.066.x frontend. The next release will
require at least 2.067.0 or maybe even 2.068.0 (still TBD). This may
unfortunately rule out GDC for the time being.
- Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27
Homepage: http://vibed.org/
DUB package: http://code.dlang.org/packages/vibe-d
GitHub: https://github.com/rejectedsoftware/vibe.d
Feb 09 2016
extrawurst <stephan extrawurst.org>
On Tuesday, 9 February 2016 at 19:16:49 UTC, Sönke Ludwig wrote:
This release brings some larger changes:
- The library has been split up into sub packages: code,
utils, data,
http, mail, diet, mongodb, redis and web. This is an
intermediate
step to moving the individual packages out to separate
repositories
with independent version numbers.
[...]
Awesome! Thanks for all the hard work.
--Stephan
Feb 09 2016
On Tuesday, 9 February 2016 at 19:16:49 UTC, Sönke Ludwig wrote:
This release brings some larger changes:
- A lot of work went into performance tuning. Single-core
performance
of the HTTP server is improved by about +50% and multi-core
performance scales properly again after excessive lock
contention
sneaked in in one of the previous releases. The number of
worker
threads is now also properly determined on all systems
(including
multi-CPU), which should fix the numbers for multi-threaded
benchmarks (an update to the TechEmpower benchmark suite is
on the
way).
I look forward to reading the numbers, and seeing how it
compares, to other web servers :)
Nick
Feb 09 2016
On 02/09/2016 09:16 PM, Sönke Ludwig wrote:This release brings some larger changes: ...Changelog looks very exciting, good work!
Feb 09 2016
On 2/9/16 2:16 PM, Sönke Ludwig wrote:- Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27 Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.dCongrats!! -- Andrei
Feb 09 2016
On 2016-02-09 19:16:49 +0000, Snke Ludwig said:- Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27Great stuff!! Thanks a lot for your engagement. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Feb 10 2016
On 9 February 2016 at 20:16, S=C3=B6nke Ludwig <
digitalmars-d-announce puremagic.com> wrote:
This release brings some larger changes:
- The library has been split up into sub packages: code, utils, data,
http, mail, diet, mongodb, redis and web. This is an intermediate
step to moving the individual packages out to separate repositories
with independent version numbers.
- A lot of work went into performance tuning. Single-core performance
of the HTTP server is improved by about +50% and multi-core
performance scales properly again after excessive lock contention
sneaked in in one of the previous releases. The number of worker
threads is now also properly determined on all systems (including
multi-CPU), which should fix the numbers for multi-threaded
benchmarks (an update to the TechEmpower benchmark suite is on the
way).
- The REST interface generator now supports modelling collections with
native D syntax using Collection!T. It also adds support for CORS.
- The std.concurrency integration has been fixed and re-enabled - you
can now use std.concurrency without worrying about blocking the
event loop. In case of problems (std.concurrency doesn't support
passing certain kinds of values), the old implementation can still
be accessed as sendCompat/receiveCompat/...
- Compiles on 2.066.0 up to 2.070.0. Note that this will be the last
release that supports the 2.066.x frontend. The next release will
require at least 2.067.0 or maybe even 2.068.0 (still TBD). This may
unfortunately rule out GDC for the time being.
Not a problem. We may be on 2.068 sooner than you think (I know that 2.067
has been in branch/PR forever ;-)
Iain.
Feb 10 2016
On Wednesday, 10 February 2016 at 08:50:54 UTC, Iain Buclaw wrote:On 9 February 2016 at 20:16, Sönke Ludwig < digitalmars-d-announce puremagic.com> wrote:Does your company use D?This release brings some larger changes: - The library has been split up into sub packages: code, utils, data, http, mail, diet, mongodb, redis and web. This is an intermediate step to moving the individual packages out to separate repositories with independent version numbers. - A lot of work went into performance tuning. Single-core performance of the HTTP server is improved by about +50% and multi-core performance scales properly again after excessive lock contention sneaked in in one of the previous releases. The number of worker threads is now also properly determined on all systems (including multi-CPU), which should fix the numbers for multi-threaded benchmarks (an update to the TechEmpower benchmark suite is on the way). - The REST interface generator now supports modelling collections with native D syntax using Collection!T. It also adds support for CORS. - The std.concurrency integration has been fixed and re-enabled - you can now use std.concurrency without worrying about blocking the event loop. In case of problems (std.concurrency doesn't support passing certain kinds of values), the old implementation can still be accessed as sendCompat/receiveCompat/... - Compiles on 2.066.0 up to 2.070.0. Note that this will be the last release that supports the 2.066.x frontend. The next release will require at least 2.067.0 or maybe even 2.068.0 (still TBD). This may unfortunately rule out GDC for the time being.Not a problem. We may be on 2.068 sooner than you think (I know that 2.067 has been in branch/PR forever ;-) Iain.
Feb 10 2016
Am 10.02.2016 um 09:50 schrieb Iain Buclaw via Digitalmars-d-announce:Not a problem. We may be on 2.068 sooner than you think (I know that 2.067 has been in branch/PR forever ;-) Iain.Really glad to hear that! BTW, is anything moving w.r.t. integrating GDC (and LDC) to the auto tester for the DMD frontend?
Feb 10 2016
On 10 February 2016 at 10:49, S=C3=B6nke Ludwig < digitalmars-d-announce puremagic.com> wrote:Am 10.02.2016 um 09:50 schrieb Iain Buclaw via Digitalmars-d-announce:Don't think so. We have Travis CI building DMD with GDC and LDC for each PR, however I don't know whether or not the auto-tester takes the success/failure of these builds into account.Not a problem. We may be on 2.068 sooner than you think (I know that 2.067 has been in branch/PR forever ;-) Iain.Really glad to hear that! BTW, is anything moving w.r.t. integrating GDC (and LDC) to the auto tester for the DMD frontend?
Feb 10 2016
Dne 10.2.2016 v 09:50 Iain Buclaw via Digitalmars-d-announce napsal(a):
On 9 February 2016 at 20:16, Sönke Ludwig
<digitalmars-d-announce puremagic.com
<mailto:digitalmars-d-announce puremagic.com>> wrote:
This release brings some larger changes:
- The library has been split up into sub packages: code, utils, data,
http, mail, diet, mongodb, redis and web. This is an intermediate
step to moving the individual packages out to separate repositories
with independent version numbers.
- A lot of work went into performance tuning. Single-core performance
of the HTTP server is improved by about +50% and multi-core
performance scales properly again after excessive lock contention
sneaked in in one of the previous releases. The number of worker
threads is now also properly determined on all systems (including
multi-CPU), which should fix the numbers for multi-threaded
benchmarks (an update to the TechEmpower benchmark suite is on the
way).
- The REST interface generator now supports modelling collections
with
native D syntax using Collection!T. It also adds support for CORS.
- The std.concurrency integration has been fixed and re-enabled - you
can now use std.concurrency without worrying about blocking the
event loop. In case of problems (std.concurrency doesn't support
passing certain kinds of values), the old implementation can still
be accessed as sendCompat/receiveCompat/...
- Compiles on 2.066.0 up to 2.070.0. Note that this will be the last
release that supports the 2.066.x frontend. The next release will
require at least 2.067.0 or maybe even 2.068.0 (still TBD).
This may
unfortunately rule out GDC for the time being.
Not a problem. We may be on 2.068 sooner than you think (I know that
2.067 has been in branch/PR forever ;-)
Iain.
Wow, that would be awesome :)
Feb 10 2016
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?
Feb 10 2016
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.
Feb 14 2016
On Sunday, 14 February 2016 at 08:17:34 UTC, Sönke Ludwig wrote:Am 11.02.2016 um 00:24 schrieb sigod: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.0Did 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.
Feb 14 2016