It is currently March 28th, 2024, 8:01 pm

Escaping %N at display time

Get help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

Post by jsmorley »

Maybe a better character for this is [\x200b], Unicode 'ZERO WIDTH SPACE'

http://www.fileformat.info/info/unicode/char/200b/index.htm

Probably more intuitive than using the deprecated "bell" character that while it generally doesn't do anything on modern PC's, was originally designed to activate the bell on a telex machine, and for some time would activate the internal speaker on early PC's, and can still cause a sound in some cases on modern PC's.
User avatar
Yincognito
Rainmeter Sage
Posts: 7026
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Escaping %N at display time

Post by Yincognito »

jsmorley wrote: March 10th, 2019, 2:50 pm Maybe a better character for this is [\x200b], Unicode 'ZERO WIDTH SPACE'

http://www.fileformat.info/info/unicode/char/200b/index.htm

Probably more intuitive than using the deprecated "bell" character that while it doesn't do anything on modern PC's, was originally designed to activate the bell on a telex machine, and for some time would activate the internal speaker on early PC's.
Good point. I'll try that, but so far I used your idea to insert BEL into potential tag-like strings from the feed content, to be certain that the actual custom tags I use were not mistaken by the regexes. So, my custom tags will look like <0e> and such, while other tag-like content (that isn't "real" tag) will be like <[\x7]0e>. This way, when I remove content I don't need, I can't go wrong with identifying the actual tags.

That being said...I start to feel the "tears" you were talking about, albeit in a very curious way. I just increased the number of sites I get feeds from - from 7 to 14 - and suddenly my CPU usage increased to 13%, while before the impact was actually... 0 (which is why I said things went better than I expected). What's strange is that the CPU usage increased when nothing at all is happening (i.e. the aggregator is already built and the whole process is basically on "stand-by" until the next update, which I set to 1h for now). It's not from the sliding animation, I paused it and even disabled it and the increase is still happening. I would understand if the memory usage would increase or the regex would fail, but not a CPU increase on stand-by moments...unless WebParser measures (or String ones) continue to use CPU even after finishing their job. Could this be the case?
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7026
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Escaping %N at display time

Post by Yincognito »

Regarding my question, is it possible that the CPU usage increase when the measures do basically nothing to be related to Brian's reply here?
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

Post by jsmorley »

I really don't know. I don't see any reason why a WebParsr parent measure should be using excessive CPU when it is "between" UpdateRate activation's, other than a small amount used on each update of the measure to push the StringIndex values to the child measures.

I am very leery in general of any skin that is spawning 7, 14, 50 separate WebParser threads and all hitting the internet at one time. I just don't think it is designed for that kind of potential "bottleneck", and while I can't say I have ever tried to push things to the limit, or have any real sense of what the downsides are, the entire idea worries me. I would just never do it. I would have a single feed returned, and have some kind of selector, or scroll, change from one feed to the other.

But to each his own.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

Post by jsmorley »

Yincognito wrote: March 10th, 2019, 3:13 pm Regarding my question, is it possible that the CPU usage increase when the measures do basically nothing to be related to Brian's reply here?
Perhaps. There is a certain amount of work that a WebParser parent measure does on every update of the measure, which is to push the StringIndex values to all the children. While this is certainly far less work than when the thread that is hitting the internet, downloading a site, and parsing it, I imagine it is not trivial if you have enough WebParser parents and child measures.
User avatar
Yincognito
Rainmeter Sage
Posts: 7026
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Escaping %N at display time

Post by Yincognito »

jsmorley wrote: March 10th, 2019, 3:26 pm I really don't know. I don't see any reason why a WebParsr parent measure should be using excessive CPU when it is "between" UpdateRate activation's, other than a small amount used on each update of the measure to push the StringIndex values to the child measures.

I am very leery in general of any skin that is spawning 7, 14, 50 separate WebParser threads and all hitting the internet at one time. I just don't think it is designed for that kind of potential "bottleneck", and while I can't say I have ever tried to push things to the limit, or have any real sense of what the downsides are, the entire idea worries me. I would just never do it. I would have a single feed returned, and have some kind of selector, or scroll, change from one feed to the other.

But to each his own.
You didn't understand what I did, jsmorley. See if you refused to look at my skin? :D
What you said is exactly what I'm doing: the skin is very short, the whole process is designed for extremely low CPU usage ... exactly because I use just one WebParser parent measure (along with just one child), which gets the feed data one site after another, in a sequentially/synchrounous way. Basically, that one WebParser is "re-used" to get data from subsequent feeds (gets the 1st, adds it to the aggregator String measure, then the same WebParser measure gets the 2nd, adds it to the aggregator, and so on, until it finally "exits the loop" when the URL holding the address to be queried is "" - which means I got to the end of the URL list - and this happens before executing the WebParser again, so there is no danger of endlessly executing it). By the way, all the measures and meters except the WebParser (and its only child used to store the <feed>...</feed> string) have UpdateDivider=-1 set on them, which means they are only executed on demand.

I really can't figure out why the CPU increase happens. In my view, there is absolutely no reason for this to happen. As I said, I would understand memory issues, or regex failures, if the string is too long, for example - but none of this happens. Everything works fine, but the CPU usage jumps. Disabling the aggregator String measure reduces the CPU usage to 6% or 7% (basically half as before), but again, that measure is inert/doing absolutely nothing, once the process exited the "loop". Unless, of course, the WebParser child measure keeps sending data to the aggregator - but I commented that thing too, so...

Are you interested in looking a little to the code? If you don't, tell me - I won't be upset or something. ;-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

Post by jsmorley »

I think not, sorry. I doubt I would have any valuable insight into this, and I'm just not willing to expend the time and brain cells on something I just have a hard time with in principle. There is a reason why "aggregators" like Google News and Feedly run on huge server farms on the back-end, and the forward-facing client is actually very light. I just think this is trying to push Rainmeter too hard, but that's just my personal opinion, based on nothing other than a gut feeling.
User avatar
Yincognito
Rainmeter Sage
Posts: 7026
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Escaping %N at display time

Post by Yincognito »

jsmorley wrote: March 10th, 2019, 3:51 pm I think not, sorry. I doubt I would have any valuable insight into this, and I'm just not willing to expend the time and brain cells on something I just have a hard time with in principle. There is a reason why "aggregators" like Google News and Feedly run on huge server farms on the back-end, and the forward-facing client is actually very light. I just think this is trying to push Rainmeter too hard, but that's just my personal opinion, based on nothing other than a gut feeling.
Ok then - I'll get to the bottom of this, eventually. Just one question though: the WebParser child also has UpdateDivider=-1 set on it (while its parent is having that large UpdateRate and no UpdateDivider, as per your advice). Is that UpdateDivider setting of any use on a WebParser child, or could it be causing any problems whatsoever?
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

Post by jsmorley »

Yincognito wrote: March 10th, 2019, 3:57 pm Ok then - I'll get to the bottom of this, eventually. Just one question though: the WebParser child also has UpdateDivider=-1 set on it (while its parent is having that large UpdateRate and no UpdateDivider, as per your advice). Is that UpdateDivider setting of any use on a WebParser child, or could it be causing any problems whatsoever?
The only thing UpdateDivider=-1 would control on a WebParser child measure is when any IfCondition, IfMatch, OnUpdate, OnChange "actions" are executed. It will have nothing to do with how the string value is populated in the measure, that is controlled by the parent. I don't think there is any harm in using it on them, but really little value as well.
User avatar
Yincognito
Rainmeter Sage
Posts: 7026
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Escaping %N at display time

Post by Yincognito »

jsmorley wrote: March 10th, 2019, 4:01 pm The only thing UpdateDivider=-1 would control on a WebParser child measure is when any IfCondition, IfMatch, OnUpdate, OnChange "actions" are executed. It will have nothing to do with how the string value is populated in the measure, that is controlled by the parent. I don't think there is any harm in using it on them, but really little value as well.
Ok, thanks.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth