Joeish W <
joeish80829@yahoo.com> writes:
> (defcfun ("cv_create_Mat" create-mat) (%cv-mat :garbage-collect t))
>
> a million times to bench mark it it was actually 4 times slower than
> my original code....I really do need this all to be fast code, since
> computer vision can benefit from the speed. Also I noticed when I
> ran the (create-mat) function 1,000,000
times my ram went up a tiny
> bit and didn't go down..Is that normal for finalizers.
Well, that it is a bit slower is not really surprising because:
1. CLOS classes are instantatied to wrap the pointer
2. The trivial garbage needs to keep track of the objects
3. The conversion code is done by generic functions.
However, this is solvable. But I really would not focus on this right
now. I cannot really imagine that creating the matrix is the
bottleneck.
With respect to the memory, as long as it does not grow indefinitely I
would not worry about it. The trivial garbage package might introduce
some memory overhead which is not directly reclaimed by the garbage
collector.
> When I use
> with-* macros or manual MM I don't get an increase in ram on my
> system. I would like to include finalizers in my library but is there
> any way to
overcome these obstacles to make that happen...Again the
> time you took to help me on this is much appreciated. :)You really
> helped me to understand.
Using `with-*` macros is a good idea. Inside these macros you can
do the manual garbage collection and avoid maybe the generic type
conversion. But to make it robust the `with-*` macros will not (I
expect) be faster than the code you have now.
Making the code fast is certainly doable and not hard, but you should
first make it work and figure what needs to be fast and which
conveniences you are willing to give up for the speed improvement.
Wim Oudshoorn
_______________________________________________
Cffi-devel mailing list
Cffi-devel@common-lisp.nethttp://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel