@Kornel: I did quite a few changes in the CMakeLists.txt, introducing
one new feature and tweaking the compiler options. Can you have a look
and see if I made any obvious mistakes? You know my CMake isn't so good...
@all: The new feature is my use of the clang 'leak sanitizer':
https://clang.llvm.org/docs/LeakSanitizer.html
You may have noticed that I have my own code to track memory allocations
(the memlog stuff), but that only goes so far and only tracks
allocations in lux' own code - and only if it's explicitly coded. The
'leak sanitizer' works at a lower level (a bit like valgrind) and also
checks activity in the linked-in libraries. It's also allegedly quite
fast. I may eventually throw out my own allocation tracing code in it's
favor. Use of the feature is activated by passing -DLEAK_SANIZER=ON to
cmake, and my own allocation tracing by -DMEMLOG=ON.
Neither of the two is necessary, but I noticed a *strange effect*, maybe
some of you have seen such behavior, please get in touch:
When I do specific stuff in lux repeatedly (like, show a slide show of
exposure-fused brackets) - memory use slowly 'creeps up', but it does
not seem to rise at a steady rate like a 'real' memory leak, instead the
increase slowly lessens and seems to pretty much stop after some time.
When I noticed this behavior, I feared for the worst and suspected I had
a hard-to-detect leak somewhere, but my own tracking of new/delete
showed no unmatched pairs. This doesn't necessarily mean all is well
(there may be pointer type issues), so I threw in the leak sanitizer.
And to my surprise *the problem disappeared*. Like altogether. There was
no more creeping memory use buildup. The leak sanitizer finds no fault,
either. Now it might be that the implementation of malloc/free which
underlies C++ new/delete may be at fault, but I'm not really competent
to figure out what's going on here, help would be welcome!
Be that as it may, the sanitizer is lightweight so I may just have it
on/in all the time anyway and benefit twofold: the 'memory creep-up' is
gone, and I'm instantly notified if there are leaks detected (it even
found a 40-byte leak in libexiv2...)
Apart from that, the recent pushes to master after 1.0.8 should produce
a noticeable increase in stitching/fusing speed (and hopefully no creepy
errors) - on my system, I was able to stitch a small-ish regular
panorama (6X16MP JPG image stripe to 60MP spherical) in 29 seconds, vs.
50 seconds using hugin_stitch_project. This is very encouraging!
Kay
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/b0689c87-a230-453e-e8c8-3818caaadd1b%40yahoo.com.
