A large portion of the VTK-m filters are now compiled into the
vtkm_filter library. These pre-built filters now don't include
the respective hxx file to remove the amount of template
instantiation users do.
To verify that this removal reduces compiler memory ( and maybe time)
I profiled the compiler while it building filter tests in debug mode.
Here is a selection of results:
```
CleanGrid 10.25s => 9.01s, 901MB => 795MB
ExternalFaces 13.40s => 5.96s, 1122MB => 744MB
ExtractStructured 4.69s => 4.75s, 492MB => 492MB
GradientExplicit 22.97s => 5.88s, 1296MB => 740MB
```
8d3f37664 CreateBuffers improvements suggested by Rob Maynard
c072e4ed2 Add a CreateBuffers helper function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2320
The array given to `ArrayHandleGroupVec` should really have a number of
values that divides evenly among the `Vec`s. Previously, if this was not
the case, an error exception was thrown. These changes allow this
condition. Extra components are dropped and a warning is logged.
Most `ArrayHandle` implementations must create an
`std::vector<vtkm::cont::internal::Buffer>` object. It is most helpful
to create it in the constructor when initializing the superclass (so the
superclass does not have to create it's own). Added a `CreateBuffers`
convenience function to make it easy to build these vectors.
64ff68421 Use TypeToString to demangle symbol in UnknownArrayHandle.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2315
d82fc92a1 Fix for serializable type names that change base C types
88eed2bbe Make sure all C scalar types are in TypeListScalarAll
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2312
MR !2311 fixed an issue where some base C types were not recognized by
`SerializableTypeString`. However, the fix was such that different types
with the same layout had the same string. For example `char` and
`signed char` both were given the string `I8`. That meant that the
serialization/deseralization would work, but the deserialization could
change the type. That could cause problems if two arrays were expected
to have the same type but did not.
This change undoes much of MR !2311 and redoes it so that the types are
correct.
C++ template considers some types different even though they have the
exact same format. For example `int`, `long`, and `long long` all match
different types even though they all represent either signed 32-bit ints
or signed 64-bit ints.
List all these possible types in
`TypeListScalarAll`.
ec4a434dc Include all int types in SerializableTypeString
d9fe6a546 Fix ArrayHandleCast serializable type name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2311
- It explicitly instantiate its concrete templates to
the supported types.
- It disables implicit template instantations for the
the supported types.
- Also fix small typo in Contour impl include guards
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Previously, `SerializableTypeString` was specialized only for the VTK-m
defined int types (`Int8`, `UInt8`, `Int16`, etc.). You would think this
would cover all the base int types, but in fact C++ defines multiple int
types that have the exact same bit layout. These duplicates will not
match each other when matching template specializations. For example,
`char` is either the same as `signed char` or `unsigned char`, but will
match neither. Likewise, `long` is the same as either `int` or `long
long`, but all these types will match different template
specializations.
Now all integer types are covered.
The specialization for SerializableTypeString for ArrayHandleCast tried
to get the serialization for the base type and the storage tag. This is
wrong since the storage tag itself is not seralizable nor has a type
string. Instead, just record the type name for the sub ArrayHandle
itself.
Previously you had to create a special virtual object to place in the
`Buffer`'s metadata. This added a lot of difficulty that is probably
unnecessary.
Instead, just have `Buffer` hold an arbitrary object and some simple
functions to copy and delete it. There may be issues with type safety
across translation units, but we'll deal with that when/if we run into
it.
ArrayRangeCompute.hxx was removed, but other code may be including it.
The file was replaced. It now just includes its replacement
(ArrayRangeComputeTemplate.h) and forces a deprecation warning.
e3dfa4891 Do not attempt to move non-trivial objects in Variant
8e11b3ecd Remove ArrayPortalCheck
21db210a7 Make separate exec and cont versions of Variant
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2274
