Trying again then: I see two types of option checking
1) Inside XXXSetFromOptions(), I believe we can protect these so they are
only called when they can actually have an affect to actually set some options
2) All the various -xxx_view that are in the code to help with understand
what it is doing, what the matrices look like etc. For example -ksp_mat_view
that allows saving the matrix right before a solve or -pc_factor_mat_view etc.
These are called in tight loops sometimes because we want to check things in
those tight loops.
It may be possible to organize all the -xxx_view calls through a universal
PetscObject/XXXViewFromOptions() call that gets dropped into the source code
wherever we like. But we have a runtime option that short-circuits the call so
no checks are actually made and hence no cost. Conceivably you could even apply
this option selectively to only some objects.
I’ll see if I can organize XXXViewFromOptions() universally and make a
branch to see if this API makes sense. Regardless using XXXViewFromOptions()
consistently will be better than the hodgepodge we have now.
Barry
On Nov 25, 2013, at 6:38 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes:
>
>> If we put all the options passed in into a hash table then won’t a
>> PetscOptions look up be pretty cheap, compute the hash, look in the
>> table, check that the strings match with a strncmp, done (usually)
>> and at worst do 2 or 3 string compares?
>
> Yes, I have always thought that we should use a hash for the options table...
>
>> If we adopt the view that an options check is very cheap that we
>> don’t need to worry much about options being rechecked right?
>
> ... however, I don't think it changes the picture that we should move
> options testing out of the fast path for algorithms. The hash just
> pushes the pain point down somewhat, most importantly, in a way that is
> scalable in the total number of options in the options table. But with
> a big options table, it's still a lot of string hashing and a lot of
> likely cache misses probing into the options hash.
>
> I would like to make PETSc competitive for integrating 20-species
> chemical systems, and I don't see room for string operations in that
> world.
