Matthew Knepley <knepley at gmail.com> writes: > On Sat, May 4, 2013 at 6:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > >> Dharmendar Reddy <dharmareddy84 at gmail.com> writes: >> >> > There is no CHKMEMQ statements. >> >> I meant inside the VecScale() implementation. It turns out that >> PetscStackCall(), which is used around all BLAS/Lapack functions, among >> others, currently includes CHKMEMQ. >> >> CHKMEMQ walks all allocations to check for memory corruption. It can be >> rather time consuming when many objects (or other small allocations) >> occur. If you run with '-malloc 0', the performance problem will go >> away. When PETSc is configured --with-debugging=0, CHKMEMQ does nothing >> unless you pass '-malloc' (so it'll be fast by default in optimized >> mode). >> >> petsc-dev, is this performance degradation of multiple orders of >> magnitude really tolerable? Should we turn off malloc checking around >> BLAS/Lapack functions unless the user passes an extra flag (but leave >> sentinel checking around user functions because that's where almost all >> the memory bugs are)? >> > > I was for eliminating these before.
I didn't realize that never got any action. Here's a pull request to fix it. https://bitbucket.org/petsc/petsc/pull-request/33/consolidate-petscstack-and-add/diff
