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)?
