On Wed, 31 Jul 2002, Guy Baruch wrote:
> how does it compare with rational's purify tool ? > or any other such commercial tool ? first - you can try valgrind by yourself. you download it, compile it, run it (with a flag to increase the number of stack frames to show, and another flag to tell it to bypass gcc 2.96 bugs - relevant on systems with gcc 2.96). then you run a binary application with it. its not as developed as purify or insure++, but: 1. for linux, there is no purify. there is insure++. 2. purify is available for other platforms - valgrind only for linux on x86 (for now). 3. the multi-threaded support in valgrind is not necessarily complete - unless something changed in the past 3-4 weeks (and it does seem to develope very fast lately). 4. valgrind has some 'profiling' support in it. purify does nto - you need to purchase quantify (another rational product for another few K$). ofcourse, quantify is more complete then valgrind in the profiling aspect (at least it seems so - i didn't try the profiling part of valgrind - only read what it can give). 5. with valgrind, you don't need to compile nor link the application differently then you do for a regular run - you will ofcoruse want to compile it with debug info, which you do anyway (you do - don't you?). with purify - you need to link the application with the purify tool - but you compile it regularly. with insure++ - you need to both compile and link the code with insure++. they claim there is a mode in which you only link the application with insure++, and then you get less info then if you compile the code with it. i didn't try this 'linking only' mode - the documentation was iased towards a full compile with insure++. 6. insure++ had some problems with various libraries - i needed to tweak the linking part in order to get the application i tried it with (few 10Ks of lines). in general, you should note that you don't use any of these tools as often as you compile the application, so it doesn't matter if you need to spend a _little_ more time on setting things up. this is why i think that the need to link with purify is not so bad - its the compilation part that takes most of the time. linking, even for large projects, usually completes within several minutes, and since purify caches the libraries it instruments, this is usually not that bad. on the first time of instrumentation - especially for c++ code - this could be alot. yet, valgrind does not cache anything, and needs to re-instrument on every run. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
