search

Active-CSS / active-css

The epic event-driven browser language for UI with functionality in one-liner CSS. Over 100 incredible CSS commands for DOM manipulation, ajax, reactive variables, single-page application routing, and lots more. Could CSS be the JavaScript framework of the future?
https://activecss.org
Other
42 stars 7 forks source link

Investigate potential runtime performance upgrade #122

Closed bob2517 closed 2 years ago

bob2517 commented 3 years ago

Currently the runtime event flow is the most computationally less expensive way to do the events. But it possibly could be improved upon. After the first run of checking if an element matches an event, this data could be mapped to the id of the event receiver and later used instead of the regular flow. The most important thing about this is that whenever the DOM changes in a way that could influence the selections for an element, that the remembered selector mapping for all events are removed so it can be regenerated the next time an event is run.

So investigate and see if it's worth doing. The results may not be particularly noticeable on fast devices, but it's worth doing for less powerful ones.

This upgrade won't affect load time, and would be a runtime performance improvement.

bob2517 commented 3 years ago

As an aside, I just put version 2.5.0 live, went into some documentation live and tried a Lighthouse test in Chromium.

100%! I'd never seen the fireworks before - that's really cool!

So loading speed is great. But I bet I can make the SPA interaction even faster by doing this issue, if it works. It's already pretty instant on my machine, but I bet on a slower computer a speed improvement would be noticeable.

bob2517 commented 3 years ago

Would be nice to do this for 2.8.0.

bob2517 commented 2 years ago

On this today. I'll do some pseudo-code and assess whether or not it's worth doing. The plan is to get all the outstanding issues resolved in some form or another before doing a general review and starting on the extension, which is a more meaty task.

bob2517 commented 2 years ago

I'm beginning to think this is not worth doing - not because I can't be bothered - but because there's a danger it ends up making things slower. The tiniest action will result in a DOM change that can affect selections. I'd have to isolate which selections had been affected and then remove them from memory so that fresh selections could be made. That would add overhead that would defeat the purpose. There's no way, without doing DOM queries or comparisons of some kind, of knowing whether or not an element has changed into a different selector set.

It was a while ago - there may have been some workaround that prompted me to come up with this idea. Will investigate further.

bob2517 commented 2 years ago

Yeah - this is only going to work at a lower level - it would possibly work as a browser optimization - the overhead is not worth it. Closing this issue.