Introducing vibe.d!

[Sönke Ludwig]

Hi Alexandre,

I'll try to answer as good as I can, please excuse if I got part of your 
question wrong. So I see two parts that can be slow:

1. The application runtime performance. Due to additional debug checks 
and less optimization, debug builds will run slower than release builds, 
but this usually gets important only for very high load scenarios for 
typical vibe.d/D applications. So this is usually nothing to worry about 
during development. If, however, a release build is required to get 
acceptable performance, it can easily double the build time.

2. The edit->compile->run->test cycle during development. This will be 
similar to Java in that it will usually require the whole application to 
be rebuilt and restarted. Building a vibe.d application currently takes 
about 12 s for most applications. It can get much slower, though, if the 
application makes heavy use of templates or compile-time function 
execution (this is the case for Diet templates [1], for example).

    Having said that, there are ways to get around this in certain 
situations. At least on Linux (on DMD 2.064 and up) this is now possible 
relatively easily using core.runtime.Runtime.loadLibrary. Using that, 
individual components can be built as small shared libraries and loaded 
dynamically into the running process. Remedy Entertainment has done 
something similar before Runtime.loadLibrary was available [2].

Best regards,
Sönke

[1]: http://vibed.org/docs#html-templates
[2]: http://www.youtube.com/watch?v=FKceA691Wcg


Am 04.11.2013 17:40, schrieb Alexandre Riveira:
> Hi Sönke,
>
>
> Congratulations for your hard work.
>
>
> One question,
> How do you think your framework running in development mode where a huge
> amount of models with many business rules exist. A system under
> development can be slow, like java where a signature change in the
> method requires reload of the whole application.
>
> Alexandre Riveira
>
>
> On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps. It combines asynchronous I/O with
>> core.thread's great fibers to build a convenient, blocking
>> API which can handle insane amounts of connections due to
>> the low memory and computational overhead.
>>
>> Some of its key fatures are:
>>
>>  - Very fast but no endless callback chains as in node.js
>>    and similar frameworks
>>  - Concise API that tries to be as efficient and intuitive
>>    as possible
>>  - Built-in HTTP server and client with support for HTTPS,
>>    chunked and compressed transfers, keep-alive connections,
>>    Apache-style logging, a reverse-proxy, url routing and
>>    more
>>  - Jade based HTML/XML template system with compile-time
>>    code generation for the fastest dynamic page generation
>>    times possible
>>  - Built-in support for MongoDB and Redis databases
>>  - WebSocket support
>>  - Natural Json and Bson handling
>>  - A package manager for seemless use of extension libraries
>>
>> See http://vibed.org/ for more information and some example
>> applications (there are some things in the works such as an
>> etherpad clone and an NNTP server).
>>
>> vibe.d is in a working state and enters its first beta-phase
>> now to stabilize the current feature set. After that, a
>> small list of additional features is planned before the 1.0
>> release.
>>
>> The framework can be downloaded or GIT cloned from
>> http://vibed.org/ and is distributed under the terms of the
>> MIT license.
>>
>> Note that the website including the blog is fully written
>> in vibe and provides the first stress test for the
>> implementation.
>>
>> Regards,
>> Sönke
>