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
