RejectedSoftware Forums

On Mon, 24 Feb 2014 17:30:23 GMT, Dicebot wrote:

On Mon, 24 Feb 2014 17:44:30 +0100, Sönke Ludwig wrote:

If I ever considered using vibe.d for perfomance-critical project, I'd likely just fork it and provide status codes based rendering alternative. But that is not a solution you are loking for :)

You can just set HTTPServerResponse.statusCode instead of throwing a
HTTPStatusException, no need to fork anything. And as said, I intend
to avoid the exception for the 404 status case, too.

Ah, I didn't know that. Will it also trigger custom error page handler properly?

No, a missing body would mean that a 404 is sent. But I guess we could make an exception and call the error handler with the existing status code for !res.headerWritten && res.satusCode >= 400. Does that sound sane?

On 24/02/14 17:04 , Stephan Dilly wrote:

On Thu, 20 Feb 2014 21:05:29 GMT, Dicebot wrote:

On Thu, 20 Feb 2014 19:08:46 +0100, Sönke Ludwig wrote:

I definitely think that 2) is the absolute minimum that has to be done
(it would probably even be enough to resolve symbols for the stack trace
lazily). And probably when that is done, there isn't even a real problem
anymore (the 404 case should still be changed).

No, it won't be enough, I have made some quick tests with hacked changed druntime. You will never ever be able to use exceptions efficiently if those are allocated (especially if it is GC allocation that can trigger collection). It may not be notable if normal processing code also allocates regularly but than it does not make any sense to speak about performance at all.

We use exeptions in similar way in some Sociomantic code but both conditions are strictly conformed (custom runtime + always reuse instances). It is natural desire because of convenience but exceptions were never designed for throwing performance (and D spec explicitly warns about it) so you can't get it without making some sacrifices and/or restrictions. Prohibiting storing exception instances (or doing fiber switch inside catch) is smallest such sacrifice that can work.

An alternative pattern is to use version exceptions to be immutable in release code (with no fancy custom formatting) and costly allocated in debug mode.

In practice most applications don't really care though same as they don't pay much attention to allocations in user code.

Sooo... what is the way to go here ?
I recently build the first component at work using vibe.d (a REST api) that performs quite nice as long as everything goes fine. but totally poos itself when requests reach an invalid url, that burns the CPU because of this issue..

And if you could comment some more about the user's code error handling
except vibe.d 's http or internal exception handling. I still not have a
clear idea how my code should be made efficiently when functions like
validateEmail or many other examples i can find are based on exceptions
by using enforce and big try catch statements. Is it better to rewrite
everything by avoiding exceptions or keeping that style can be valid
?(with additional improvements that may happen like the error traces in
release compiling etc).

Am 24.02.2014 20:03, schrieb Dicebot:

On Mon, 24 Feb 2014 17:41:54 GMT, Sönke Ludwig wrote:

No, a missing body would mean that a 404 is sent. But I guess we could make an exception and call the error handler with the existing status code for !res.headerWritten && res.satusCode >= 400. Does that sound sane?

Maybe it is better to define extra flag for that and provide a small helper similar to errorOut that both changes status code and sets "error" flag? So that preserving original rendering becomes possible.

The !res.headerWritten already achieves that. As soon as a body is
written, this will become false and thus the error callback isn't
called. The only thing that needs to be distinguished is the 404 case
(because no handler wrote a reply) and a manually set error code that
should trigger the error handler.

But I on pure theory field right now, you'd better ask extrawurst or other guys who actually do projects with vibe.d right here and now :)

Also I wonder what can be done with REST & Co to provide some alternative to exceptions while still preserving the API.

Nothing pretty, I guess. Either you'd have to work with standardized
return codes, or you'd give up the unified interface between the local
implementation and the REST client proxy class (by adding additional
parameters or return values to the proxy class for handling HTTP errors).

Really, I think that exceptions simply have to get fast enough to not be
an issue if they are thrown once per request. They can be a huge help,
especially in a server environment as a safety net and it would be
really sad to abandon them just because of a naive implementation.

On Wed, 26 Feb 2014 20:37:39 GMT, Marc Schütz wrote:

Good news:
http://forum.dlang.org/post/jdczqcybrkflihvbbkql@forum.dlang.org

With Adam Ruppe's patches in druntime, dynamic and static exceptions are now equally fast, but only if toString() is not called. So this should really be disabled in production mode.

Good news! Yes, toString should only be called for logDebug messages, which should be evaluated lazily only when a logger actually accepts debug messages. However, this parameters to the log functions are currently auto ref instead of lazy, due to historical DMD reasons. I'll test lazy again now.

The other place where toString is used is for the HTTPServerErrorInfo.debugMessage field, I'll add a HTTPServerOption for that to disable it.