Replaced and removed the CryTimer (gEnv->pTimer). The new TimeSystem is a merger of the current time functionality found in the engine.
* Rename TimeSystemComponent.h/.cpp to TimeSystem.h/.cpp
* Adding New TimeSystem
* remove old timer cvars
* small improvements to the time system.
- updated parts to use the time conversion functions.
- in AdvanceTickDeltaTimes applying t_simulationTickScale is now uses doubles instead of floats.
* Replace gEnv->pTimer / ITimer usages with TimeSystem
* Updating usages of AZ::TimeMs{ 0 } and AZ::TimeUs{ 0 } to AZ::Time::ZeroTimeMs and AZ::Time::ZeroTimeUs
* red code the CryTimer
* using TimeUs instead of TimeMs is some cases + updating usages of old cvars to new
Signed-off-by: amzn-sean <75276488+amzn-sean@users.noreply.github.com>
- Fix error with EngineFinder using the wrong path to locate project.json
- Simplified and expanded clang detection
- Remove forcing clang-12 for builds and will rely on the new cmake detection of clang by default
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
the owner has removed it!
This fixes the issue by forcing NameDictionary to not transfer
ownership. This means ComponentApplication()::Destroy will fully destroy
the NameDictionary before the OS::Allocator is destroyed.
In Windows the bug was not happening when running AssetProcessorBatch
because for Windows, _exit() is called before the application shutsdown
forcing all module to properly decrease the reference count of
EnvironmentVaqriableHolderBase::m_useCount for NameDictionary.
In MacOS, there's no _exit() so when the NameDictionary destructor was being called
before existing the application the reference count wouldn't be 0, and
would eventually try to destry the NameDictionary BUT the OS::Allocator
was already destroyed.
Signed-off-by: galibzon <66021303+galibzon@users.noreply.github.com>
This change adds a `DomBackend` interface and a `DomBackendRegistry` for backend discovery (currently not hooked up to anything) alongside a JSON backend implementation.
The JSON backend comes with a small suite of unit and performance tests. The unit tests validate generic DOM conversion to and from serialized JSON and rapidjson::Document objects (the support for which lives in `JsonSerializationUtils.h`).
The performance tests show a throughput decrease compared to directly using the rapidjson serializer when mirroring our current pattern of copying strings from the serialized JSON representation, but with the coming in-memory store we have the opportunity to keep the buffer in memory and deserialize in-situ using rapidjson's API, which is consistently at least 100MiB/s faster on my machine (Ryzen Threadripper 3970X). The first parameter is the nested object complexity (N*N, objects with N keys comprised of arrays with N values) and the second parameter is the base size of the strings within each entry of this object.
```
----------------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
----------------------------------------------------------------------------------------------------------------------
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/5 0.050 ms 0.050 ms 10000 bytes_per_second=355.816M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/50 0.057 ms 0.057 ms 11200 bytes_per_second=386.064M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/5 4.77 ms 4.88 ms 112 bytes_per_second=364.046M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/500 11.6 ms 11.7 ms 64 bytes_per_second=554.518M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/5 0.084 ms 0.084 ms 7467 bytes_per_second=212.55M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/50 0.099 ms 0.100 ms 6400 bytes_per_second=220.608M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/5 8.22 ms 8.16 ms 90 bytes_per_second=217.847M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/500 23.2 ms 22.9 ms 30 bytes_per_second=283.56M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/5 0.070 ms 0.070 ms 11200 bytes_per_second=255.049M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/50 0.086 ms 0.087 ms 8960 bytes_per_second=253.258M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/5 6.86 ms 6.84 ms 112 bytes_per_second=260.033M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/500 22.8 ms 22.9 ms 32 bytes_per_second=283.158M/s
```
For `AZ::DOM::Document`, the current plan is to offer helper methods that can load from a file path or string using a given backend that can take advantage of in-place parsing by internally storing the serialized buffer.
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
Leaving in the print for absorbed asserts to avoid running into future situations where important asserts are accidentally absorbed
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
AMZN-Phil
SergeyAMZN
amzn-sean
AMZN-nggieber
Danilo Aimini
Guthrie Adams
rgba16f
Alex Peterson
Terry Michaels
Sergey Pereslavtsev
Guthrie Adams
chcurran
Nicholas Van Sickle
galibzon
AMZN-Phil
bosnichd
nggieber
Steve Pham
Tom Hulton-Harrop
AMZN-stankowi
AMZN-AlexOteiza
jonawals
Gene Walters
hershey5045
amzn-mike