search

Matchstic / InfoStats2

An API for JavaScript, and Objective-C
BSD 2-Clause "Simplified" License
23 stars 6 forks source link

View current registered identifiers #6

Open JunesiPhone opened 7 years ago

JunesiPhone commented 7 years ago

I notice many blocks being called multiple times in the same widget. This cause a big performance hit when the block calls an outside function. I dunno why, but if I call a function outside of the callback block, from the block and it is intensive, (such as a forecast loop) it could cause a safemode. For this i've been staying away from registering identifiers.

That being said It would be nice to see which identifiers are registered. Also a log when an identifier is registered/unregistered would be great to see. I've found through testing that body onunload is not very reliable, it would be good to see if things are working properly through the console.

Matchstic commented 7 years ago

I have tried to reduce calling of blocks in v1.0.2 for music; it will now call only twice, once when artist/album etc names change, and another when new artwork data becomes available.

Which particular callbacks are the worst offenders?

JunesiPhone commented 7 years ago

I would say anything that requires more javascript to parse. Weather is one. This is mainly due to you needing to do more with weather than anything else. To better explain, for music you take the info and put directly to innerHTML or image src. With weather it will return a JSON for forecast so you need to parse it and then loop to create the forecast. Depending on how many days you are doing, or if you're doing hourly, this could be intensive. Doing this multiple times in a row is redundant and does cause cycript to crash easily.

What I don't understand is the block is calling an outside function (which is not in text/cycript) but it seems even though you call this from inside cycript IS2 block it adds it to the cycript stack (I'm just guessing here). My theory is when you call it from the block, cycript will take the function and do its cycript magic to it. (much like when you toggle ?debug in cycript) I've noticed the "cycript stack" is much more vulnerable compared to the javascript stack. The more info that is in it the slower your code will run and the bigger the chance to crash. The only fix i've found is no longer using a weather callback or any callbacks if I can, and limiting the amount of code in text/cycript.

Matchstic commented 7 years ago

This may be nicely addressed by the changes proposed in #8