UUID result #225
UUID result #225
Conversation
Removes CqlTypeClass, to reduce the overhead from it's type. This means, that array will be treated as ambiguous types.
|
| ], | ||
| ) | ||
| } | ||
| unsafe { Vec::to_napi_value(env, vec![CqlType::to_napi_value(env, typ), value]) } |
There was a problem hiding this comment.
💭 Allocating the outermost Vec seems redundant, because the only thing that we do with it is creating a JS Array based on it. Maybe instead we could create the Array straight away?
I we employ this pattern codewide, we could even write a macro: js_array![env, ...elems], which would be analogous to vec![...elems].
There was a problem hiding this comment.
Sure, but I will prefer to update it another PR as this approach is not introduced here (and currently don't have time for such experiments).
| Vec::to_napi_value( | ||
| env, | ||
| val.into_iter() | ||
| .map(|e| CqlValueWrapper::to_napi_value(env, CqlValueWrapper { inner: e })) | ||
| .collect(), | ||
| ), |
There was a problem hiding this comment.
Same here. We could collect() the iterator directly into JS array.
CqlList and CqlSet
This means, there will be no separate case for Array, and it will be moved into the second case (as listed in |
|
So as discussed, there will be no longer ambiguity, because the problematic case of plain Array will be replaced with (Type, Array). |
Update UUID, so that we return raw bytes instead of object wrapper.
Removes CqlTypeClass, to reduce the overhead from it's type.
This means, that array will be treated as ambiguous types in result wrapping.
This provides about 25% time improvement time elapsed:
Before
After: