Faster way to fetch specific attributes?

[GnomedDev]

Is your feature request related to a problem? Please describe.
Currently, in order to fetch a couple attributes:

1. JS has to create a bunch of Attribute classes
2. Collect them into a array
3. Iterate over this array
4. Read attribute name into a string
5. Check if the attribute name is correct
6. Read the desired attribute value into a string and store it
7. Repeat from 4 until all fields are collected

This is inefficient, as we only really want to iterate over the XML and do 5, 6 and 7

Describe the solution you'd like
An API such as Tag.extractAttributes() which takes a list of keys and returns the key: value pairs in an object. This would be able to skip Attribute construction, the double iteration, and even some string conversions with extra optimization.

Describe alternatives you've considered
My existing solution works, but could be quicker.

Additional context
23% of profiled time in my application is spent in get attributes(), which is a waste, alongside 13% of time spent in get value() for Text during this loop which could be reduced with smarter key comparisons.

[justinwilaby]

Are you targeting a specific tag name for this operation or just attributes in general? Can the attribute isolation event SaxEventType.Attribute work?

[justinwilaby]

On another note - I have given this some thought before arriving at the current solution. This is a tradeoff and suites most Node/Web engineering needs and is still faster than anything else out there. If you are working with an extremely tight performance budget, I can advise on how to work directly with WASM memory to get the absolute fastest possible speeds.

I don't think this is too difficult since you already know how to work with WASM memory. Here is a crash course:

1. The Attribute struct is 120 bytes
2. The Text struct is 56 bytes
3. Offsets for name and value start at byte 56
4. Text contains a [u8] for the utf8 value field. This is stored on the stack which means Text#value is a ptr and length consisting of 8 byes total which points to the memory location somewhere on the stack.
5. Obtaining the utf8 slice from the ptr and length for each Text struct will allow you to perform comparisons without having to decode these bytes into a primitive.

I think it's worth considering a lazy generator instead of an eager loop in the case of Attributes and Text nodes on the Tag too. This would prevent the iterations you mention and could allow a pathway to object literals instead of constructed classes for output.

I can update the playground.js soon to provide a better example of how this is done. Believe me, I'd like to eliminate/optimize the JS side as much as possible too.

[GnomedDev]

I'll take a look at the Attribute event tomorrow, but making attributes into a generator sounds good as just a general improvement.

[GnomedDev]

Using the attribute event saved 60% of the runtime somehow, so thanks for that tip, since this solves the issue I'll close this.

[GnomedDev]

I took another look at my numbers and realised that I wasn't specifying the Attribute event.... Turns out this is now slower, due to createDetailConstructor for Attribute taking 50% of runtime over a 15 second subset of runtime.

[justinwilaby]

With no events specified, the WASM skips dispatching and does not pass any data over the FFI boundary. It's expected that adding 1 or more events will slow things down a bit. This isn't a parser issue, its an FFI/JS issue. Regardless, this library will still beat the performance of any other options currently available.

Calls across the FFI boundary are synchronous and will wait for the JS stack to complete before moving on. I can give assurance that the createDetailConstructor function itself is not inefficient and there isn't much at all happening in the constructor for the Attribute entity. The slice() operation in this function does copy bytes but for an Attribute, this is exactly 120 bytes which is very, very fast.

What you are likely seeing is the cycles needed for the text decoding. This assumes you are avoiding the Attribute#toJSON() call which is quite expensive and should be avoided unless absolutely necessary.

If you still need to go faster and don't mind complexity, I recommend bypassing any text decoding and run your comparisons using Uint8Array slices instead of string comparisons. If you need level 10 performance, I recommend bypassing the eventTrap and adding your own logic for reading WASM memory directly. The speeds will be as close as you can get to running the Rust binary natively.