On 10.05.2011 16:53, Robert Jacques wrote:
> Well, you are supposed to use validate first on any untrusted input. Now the
> fact that validate returns void and throws an exception and there is no
> corresponding 'isValid' routine probably is bad design.
Not to mention that validating first and
On Tue, 10 May 2011 01:15:04 -0400, Walter Bright
wrote:
On 5/9/2011 9:48 PM, Andrej Mitrovic wrote:
Well I can understand throwing exceptions when using readln() or
validate(), but decode() is used for one code point at a time.
Throwing is overkill imo.
Perhaps decode() is badly designed.
On 5/10/11, Andrej Mitrovic wrote:
> On 5/10/11, Walter Bright wrote:
>> On 5/9/2011 9:48 PM, Andrej Mitrovic wrote:
>>> Well I can understand throwing exceptions when using readln() or
>>> validate(), but decode() is used for one code point at a time.
>>> Throwing is overkill imo.
>>
>> Perhaps
On 5/10/11, Walter Bright wrote:
> On 5/9/2011 9:48 PM, Andrej Mitrovic wrote:
>> Well I can understand throwing exceptions when using readln() or
>> validate(), but decode() is used for one code point at a time.
>> Throwing is overkill imo.
>
> Perhaps decode() is badly designed.
>
It has goto's
On 5/9/2011 9:48 PM, Andrej Mitrovic wrote:
Well I can understand throwing exceptions when using readln() or
validate(), but decode() is used for one code point at a time.
Throwing is overkill imo.
Perhaps decode() is badly designed.
Well I can understand throwing exceptions when using readln() or
validate(), but decode() is used for one code point at a time.
Throwing is overkill imo.
On 5/9/2011 8:09 PM, Andrej Mitrovic wrote:
I'll have to agree that exceptions are quite slow. I was just testing
out UTF's decode() function on this UTF-8 test file:
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt .
It has a few dozen invalid UTF sequences and is a good stress-test f
I'll have to agree that exceptions are quite slow. I was just testing
out UTF's decode() function on this UTF-8 test file:
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt .
It has a few dozen invalid UTF sequences and is a good stress-test for
a decoder. The std.utf.decode function thr
On Apr 26, 2011, at 11:56 AM, Denis Koroskin wrote:
> On Tue, 26 Apr 2011 22:26:00 +0400, Sean Kelly wrote:
>
>> On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
>>
>>> On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly
>>> wrote:
>>>
Right now, traces are generated on throw. It should be
On Tue, 26 Apr 2011 22:26:00 +0400, Sean Kelly
wrote:
On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly
wrote:
Right now, traces are generated on throw. It should be possible to
generate them on catch instead. The performance would be th
On Apr 26, 2011, at 11:39 AM, Steven Schveighoffer wrote:
> On Tue, 26 Apr 2011 14:26:00 -0400, Sean Kelly wrote:
>
>> On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
>>
>>> On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly
>>> wrote:
>>>
Right now, traces are generated on throw. It sho
On Tue, 26 Apr 2011 14:26:00 -0400, Sean Kelly
wrote:
On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly
wrote:
Right now, traces are generated on throw. It should be possible to
generate them on catch instead. The performance would be th
On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
> On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly wrote:
>
>> Right now, traces are generated on throw. It should be possible to generate
>> them on catch instead. The performance would be the same either way however.
>> It would be nice to gen
On Apr 26, 2011, at 9:18 AM, Alexander wrote:
> On 26.04.2011 18:14, Sean Kelly wrote:
>
>> It would be nice to generate them lazily but I don't think that's possible.
>
> Why not? My brute-force approach works (temporarily disabling traceHandler),
> so why it couldn't be done more nicely som
> Hi,
>
> I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that exception
> handling is terrible slow even on quite fast hardware.
>
> There is a note on DM's site, saying:
>
> "Because errors are unusual, execution of error handling code is not
> performance critical."
>
> Well, sur
On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly
wrote:
Right now, traces are generated on throw. It should be possible to
generate them on catch instead. The performance would be the same either
way however. It would be nice to generate them lazily but I don't think
that's possible.
Sen
On 26.04.2011 18:14, Sean Kelly wrote:
> It would be nice to generate them lazily but I don't think that's possible.
Why not? My brute-force approach works (temporarily disabling traceHandler),
so why it couldn't be done more nicely somewhere in deh2 (I couldn't figure out
yet, how exactly)?
Right now, traces are generated on throw. It should be possible to generate
them on catch instead. The performance would be the same either way however. It
would be nice to generate them lazily but I don't think that's possible.
Sent from my iPhone
On Apr 26, 2011, at 6:20 AM, Daniel Gibson w
On 26.04.2011 15:20, Daniel Gibson wrote:
> It'd be nice to have fast(er) exceptions and still be able to get
> backtraces for uncaught exceptions (or even for caught ones on demand).
Well, quick-and-dirty solution for this (uncaught only, though) follows. Not
very nice, but "works for me" :)
Am 26.04.2011 15:16, schrieb Alexander:
> On 26.04.2011 15:13, Kagamin wrote:
>
>> Did you compare with c++ dwarf implementation?
>
> Yes, c++ is significantly faster. But it seems that my problem is solved
> already.
>
> /Alexander
It'd be nice to have fast(er) exceptions and still be able
On 2011-04-26 12:57, Vladimir Panteleev wrote:
On Tue, 26 Apr 2011 13:08:33 +0300, Alexander wrote:
Hi,
I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that
exception handling is terrible
slow even on quite fast hardware.
On my Windows box with an i7 920, a simple try/throw/catc
On 26.04.2011 15:13, Kagamin wrote:
> Did you compare with c++ dwarf implementation?
Yes, c++ is significantly faster. But it seems that my problem is solved
already.
/Alexander
Alexander Wrote:
> I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that exception
> handling is terrible
> slow even on quite fast hardware.
Did you compare with c++ dwarf implementation?
On Tue, 26 Apr 2011 16:43:26 +0400, Alexander wrote:
On 26.04.2011 12:57, Vladimir Panteleev wrote:
On my Windows box with an i7 920, a simple try/throw/catch loop runs at
about 13 iterations per second.
Well, g++ with same loop on same linux system gives ca. 16 iter/s,
which i
On Tue, 26 Apr 2011 15:43:26 +0300, Alexander wrote:
I am right?
Sounds spot-on to me :)
I recall there was a similar performance problem due to stack traces, with
the "priority send" function in the message queue implementation. The
"priority send" function constructed an exception ob
On 26.04.2011 12:57, Vladimir Panteleev wrote:
> On my Windows box with an i7 920, a simple try/throw/catch loop runs at about
> 13 iterations per second.
Well, g++ with same loop on same linux system gives ca. 16 iter/s, which
is quite OK for me.
> Perhaps DMD doesn't use SEH on Lin
Alexander:
> I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that exception
> handling is terrible
> slow even on quite fast hardware.
On Windows I have timed DMD exceptions to be about 12 times slower than
(irreducible) Java ones. I have done only a limited amount of different
ben
On Tue, 26 Apr 2011 13:08:33 +0300, Alexander wrote:
Hi,
I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that
exception handling is terrible
slow even on quite fast hardware.
On my Windows box with an i7 920, a simple try/throw/catch loop runs at
about 13 iterations per
Hi,
I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that exception
handling is terrible
slow even on quite fast hardware.
There is a note on DM's site, saying:
"Because errors are unusual, execution of error handling code is not
performance critical."
Well, sure this is (somehow)
29 matches
Mail list logo
