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


Reply via email to