www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release vibe.d 0.7.27

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
next sibling parent extrawurst <stephan extrawurst.org> writes:
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
prev sibling next sibling parent Nick B <nick.barbalich gmail.com> writes:
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
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
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
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.d
Congrats!! -- Andrei
Feb 09 2016
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2016-02-09 19:16:49 +0000, Snke Ludwig said:

   - Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27
Great stuff!! Thanks a lot for your engagement. -- Robert M. Mnch http://www.saphirion.com smarter | better | faster
Feb 10 2016
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
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
next sibling parent Suliman <evermind live.ru> writes:
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:

 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.
Does your company use D?
Feb 10 2016
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
parent Iain Buclaw via Digitalmars-d-announce writes:
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:

 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?
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.
Feb 10 2016
prev sibling next sibling parent Daniel Kozak via Digitalmars-d-announce writes:
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
prev sibling parent reply sigod <sigod.mail gmail.com> writes:
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
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
parent sigod <sigod.mail gmail.com> writes:
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
Feb 14 2016