@RhuanColor constructor:https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/pegasus.c#L1483-L1508CreateColor:https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/vanilla.c#L1905-L1926Notice anything that might cause the latter to be significantly slower?
//proposed new api to skip string type conversionCHAKRA_API JSCreatePropertyIDfromJSString( _In_ JsValueRef stringValue, _Out_ JsPropertyIdRef *propertyId){ const char16* str = nullptr; size_t strLength = 0; JsErrorCode errorCode = JsStringToPointer(stringValue, &str, &strLength); if (errorCode != JsNoError) { return errorCode; } return JsGetPropertyIdFromName(str, propertyId);}
Then using that in make_property_id instead of the JSCopyString call; the result was a 20-25% performance improvement on common api calls; not enough to catch up with the old Duktape yet but it got rid of the majority of the slowdown in the Specs battle system - to the point that I would consider it playable.
Quote from: Rhuan on September 13, 2017, 10:41:21 pmThen using that in make_property_id instead of the JSCopyString call; the result was a 20-25% performance improvement on common api calls; not enough to catch up with the old Duktape yet but it got rid of the majority of the slowdown in the Specs battle system - to the point that I would consider it playable.I think make_property_id() is only half of the puzzle - by removing the string copy from there, you've solved the problem for strings used as property keys (and 20-25% improvement indicates that happens a lot), but the problem for jsal_get_string() remains. That comes into play whenever an API takes a string parameter, and is a much more difficult problem to solve. Essentially the entire engine would need to be refactored to use UTF-16 internally.
Thanks to @Rhuan's help, we've managed to majorly optimize miniSphere's API layer; on my laptop (6th gen i7 quad), API call speed has improved fourfold. See image attached.