Aside from performance considerations, there are semantics differences
to take into account. This blog post explain why exceptions are
"better" (or, more precisely, why it is not generally a good idea to
replace exceptions by options)
http://blog.dbpatterson.com/post/9528836599 (it is in Haskell ra
I'm trying to determine the size of a Bigarray, in bytes.
I've tried several things... ending up with this as the only solution:
--
let ba_char = Hashtbl.hash Bigarray.char;;
let ba_int8_signed = Hashtbl.hash int8_signed;;
let ba_int8_unsigned = Hashtbl.hash int8_unsigned;
I think there was an article about options versus exceptions
in the OCaml journal.
If I remember well, the exceptions were faster, but I can't
find back the exact benchmark and context of this assertion.
Regards,
F.
On 04/05/2012 07:10 AM, Julien Verlaguet wrote:
2 more use cases:
1) When wri
2 more use cases:
1) When writing a deep recursion
Throwing an exception will directly jump to your "catch" block without
having to unfold every return call site on the stack one by one. Which can
be much faster if the recursion is very "deep".
2) When your exception is exceptional :-)
If Not_fou
When thinking about performance, consider the "try" keyword to take time
to execute. A try block pushes an exception handler onto a stack and
pops the stack on exit. The try block may also interfere with tail call
optimizations.
A loop like
for i = 0 to 1000 do try ... done
executes "tr
Hi,
I benchmarked two programs, in one case the main function throw an
exception that is caught, in the other the function returns an option that
is pattern matched on.
I noticed that, whether the exception is thrown or not, the option version
is always faster.
Is there any case where it makes s
*** CALL FOR TALK PROPOSALS ***
LOLA 2012
Syntax and Semantics of Low Level Languages
Sunday 24th June 2012, Dubrovnik, Croatia
A LICS 2012-affiliated workshop
http://www.ccs.neu
I'm trying to think beyond this particular problem, and it seems to me
that the current "GC speed control" for custom blocks is too simple.
Right now, we can practically only base the speed on either
- the size of a custom object relative to the expected maximum
size of all custom objects of t
CALL FOR TALK PROPOSALS
HOPE 2012
The 1st ACM SIGPLAN Workshop on
Higher-Order Programming with Effects
September 9, 2012
Copenhagen, Denmark
(the day befo
Am Mittwoch, den 04.04.2012, 13:30 +0200 schrieb Gabriel Scherer:
> May your program leak one of those GTK resources?
>
> The effectiveness of your patch seems to indicate that you have a lot
> of one of these values allocated (and that they were requesting the GC
> much too frequently). The patch
May your program leak one of those GTK resources?
The effectiveness of your patch seems to indicate that you have a lot
of one of these values allocated (and that they were requesting the GC
much too frequently). The patch solves the CPU usage induced by
additional GC, but does not change the reas
Hi,
Thanks for your suggestions. I tried to patch lablgtk2 with:
--- src/ml_gdkpixbuf.c.orig 2012-04-03 13:56:29.618264702 +0200
+++ src/ml_gdkpixbuf.c 2012-04-03 13:56:58.106263510 +0200
@@ -119,7 +119,7 @@
value ret;
if (pb == NULL) ml_raise_null_pointer();
ret = alloc_custom (&ml
12 matches
Mail list logo
