Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Am I the only one who find it pretty shocking that there even is a speedup doing this? Blizzard definitely hasn't coded addon loading very well apparently. It takes basically no time to check if a file exists or not. Perhaps they setup the environment for loading the file prior to checking that it actually exists. Maybe the results here should be communicated to Blizzard. They have recently done other enhancements to loading time, I believe. It seems there is one more change they could easily make that potentially will give a big speedup.
Its not a fact, the evidence is anecdotal so far. Needs more testing.
But dont forget, bliz has to make sure that no new files are introduced at runtime. So in one scenerio they would check for all the files referenced in the toc, if they were all there fine move on to the next. if some are missing then a special record is created which tracks the missing files (i'm just speculating)
From what i've seen the framexml log is kept in memory until all addons load then its flushed, so the log itself probably isnt the cause.
If I remember correctly, files that are referenced in TOCs and do not exist would not be loaded if created during a WoW session with a reloadUI following - the file has to exist ; even an empty file does just fine.
So it doesn't seem like they're tracking anything.
Whatever Blizzard is doing, it's clearly not good enough and needs to be optimized rather than wowace.com changing the entire files repository, as it appears to me from the information at hand.
If I remember correctly, files that are referenced in TOCs and do not exist would not be loaded if created during a WoW session with a reloadUI following - the file has to exist ; even an empty file does just fine.
So it doesn't seem like they're tracking anything.
Whatever Blizzard is doing, it's clearly not good enough and needs to be optimized rather than wowace.com changing the entire files repository, as it appears to me from the information at hand.
I agree someone should relay this information to Blizzard.
But if following a standard embed library declaration has no disadvantage (may be? I dunno), then since the files.wowace.com already has to use some scripts to create a special support for dis-embedded version of the library, I don't think it's "a big changes to the entire files repository". It is just a change to the scripts for dis-embedded zips. For the addons side, if the author decided not to follow a standard (or he was just lazy), then everything still works.
Even if Blizzard fixed this problem later, at the least this approach shuts up FrameXML.log.
1.) They give you error logs
2.) You ignore them
3.) You purposely do something that causes errors to be thrown
4.) You complain about the speed of loading, when you're purposely triggering these errors.
You can't do something that the software tells you not to do, and then complain about the fact that its affecting you negatively.
This is not a Blizzard problem.
...
You can't do something that the software tells you not to do, and then complain about the fact that its affecting you negatively.
The fact that producing these errors appears to take so much time is a Blizzard problem, and we can complain about it as much as we want.
You can complain about it all you want. Its still your issue. If you honestly think the routines that load files from .toc file, and log the errors have some manner of "bloat" in them, than I can't help you. Report the issue all you want, the fact of the matter is that you are causing the problem.
I'm honestly not trolling here. This is an error path, that involves attempting to load files, and logging to a file. If you don't want to take a performance hit from raising errors, you should alter the way you are distributing your addons, or provide utility scripts for your users to alter their .toc files.
And consider the information "relayed". Consider the answer "Don't do that".
The error log takes so long to generate is another issue.
It is not another issue, it is the issue at hand.
We have been doing this - knowingly - for a long time. It has just never occured to anyone that stating a file and logging the fact that it doesn't exist could lead to a 20% increase in loading times.
Whether or not it's an error path is irrelevant, the only thing that matters is that it would seem, quite clearly, from these numbers, that there is a lot of optimization potential here, and I do not see why Blizzard would ignore it.
The error log takes so long to generate is another issue.
It is not another issue, it is the issue at hand.
We have been doing this - knowingly - for a long time. It has just never occured to anyone that stating a file and logging the fact that it doesn't exist could lead to a 20% increase in loading times.
Whether or not it's an error path is irrelevant, the only thing that matters is that it would seem, quite clearly, from these numbers, that there is a lot of optimization potential here, and I do not see why Blizzard would ignore it.
I disagree, "we have been doing this for a long time" doesn't mean it is the right thing to do.
Even if it doesn't lead to 20% increase in loading time, if the approach generates lots of error, and we can avoid it, I don't see why we shouldn't.
They're two completely different issues:
1. WoW cliet shouldn't take so long to generate an error log.
2. An addon shouldn't generate any error.
If we can't do anything to prevent this, then there's not much to discuss. But we *can* do something, so why not try to solve *both* problems?
Tell Blizzard to fix (1), *and* we should try to fix (2) on dis-embedded zip packages.
I wouldn't feel comfortable saying that there was a causual relation between missing lua files declared in the toc and longer load times. I can observe it, but I cant explain it which means I dont really understand it.
I do think that avoiding the error messages is good style though.
By the way, the client goes over evey single file in WTF and in Addons, passing through all directories even the .svn directories. I think that it keeps this information and uses it as a mask it doesnt appear that it calls the file system driver requesting a file that doesnt exist.
It goes like
1) Get a list of all files
2) Get a list of all Toc's from step 1 (and read them)
3) Character Loading Screen
4) Load Sequence (load toc, then lua's, then sv-luas)
at one point we had ##Libs start ##libs end in toc's. Why don't you make wau scan toc files and remove entry's between these 2 lines when the user selects 'download without externals'
You assume there is potential. There isn't. Not sure what else to tell you. I'm not talking out of my ass here.
Don't do things you aren't supposed to do, its as simple as that.
I agree to an extent. But it's not "as simple as that". Ace2 is in a way "abusing" the fact that referring to a file that doesn't exist only gives a warning and not an error. Blizzard has obviously not considered that people would have a need for a more dynamic way of loading addons. However, nothing is set in stone. Blizzard has definitely changed a lot of things about how addons work since the game first came out. Some of those changes have come from community requests, I believe. Wether the Ace2 way of using embedded libraries makes it worth changing something for Blizzard, I have no idea. It all comes down to wanting to make addon loading more dynamic than it is today. That should be the reason to ask for changes if any are needed.
I use Mac so I have no experience with WAU. But if I understand it correctly WAU "moves" embedded libraries out of the addon directories and into the top-level addon directory. If this is the main cause of the problem, then perhaps WAU should also either leave an empty file for each of the libraries being referred in each addon or even better WAU could modify the TOC files and remove the file references.
WAU does not want to ever modify the toc, since it is essentially the addons identity. Also, WAU is not the only tool. It makes sense to make the changes (if any are needeed) in the zip script. The zip from files.wowace.com already has the libs removed.
Fin was going to do this once, I'm not sure if he ever finished:
A good experiment would be to read in all the files in an addons directory and concatenate them into one lua, one xml and one toc. What are load times like then? Do they change?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumfor ~20% faster loading times!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRegex: ^.*([lL]ibs\\).*$
1) lib lines in: 54 sec
2) lines grep'ed out: 44 sec
Like Rophy said, test it yourself.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo :) There is a reason we have not investigated this before.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBut dont forget, bliz has to make sure that no new files are introduced at runtime. So in one scenerio they would check for all the files referenced in the toc, if they were all there fine move on to the next. if some are missing then a special record is created which tracks the missing files (i'm just speculating)
From what i've seen the framexml log is kept in memory until all addons load then its flushed, so the log itself probably isnt the cause.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo it doesn't seem like they're tracking anything.
Whatever Blizzard is doing, it's clearly not good enough and needs to be optimized rather than wowace.com changing the entire files repository, as it appears to me from the information at hand.
I agree someone should relay this information to Blizzard.
But if following a standard embed library declaration has no disadvantage (may be? I dunno), then since the files.wowace.com already has to use some scripts to create a special support for dis-embedded version of the library, I don't think it's "a big changes to the entire files repository". It is just a change to the scripts for dis-embedded zips. For the addons side, if the author decided not to follow a standard (or he was just lazy), then everything still works.
Even if Blizzard fixed this problem later, at the least this approach shuts up FrameXML.log.
1.) They give you error logs
2.) You ignore them
3.) You purposely do something that causes errors to be thrown
4.) You complain about the speed of loading, when you're purposely triggering these errors.
You can't do something that the software tells you not to do, and then complain about the fact that its affecting you negatively.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe fact that producing these errors appears to take so much time is a Blizzard problem, and we can complain about it as much as we want.
The problem itself is that the dis-embedded zips in files.wowace.com are generating tons of errors, this shouldn't happen at all.
While I agree someone should relay this information to Blizzard, I still think something should be done at wowace.
An "official wowace package" which is generating errors at FrameXML.log doesn't look right at all to me.
And consider the information "relayed". Consider the answer "Don't do that".
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt is not another issue, it is the issue at hand.
We have been doing this - knowingly - for a long time. It has just never occured to anyone that stating a file and logging the fact that it doesn't exist could lead to a 20% increase in loading times.
Whether or not it's an error path is irrelevant, the only thing that matters is that it would seem, quite clearly, from these numbers, that there is a lot of optimization potential here, and I do not see why Blizzard would ignore it.
Don't do things you aren't supposed to do, its as simple as that.
I disagree, "we have been doing this for a long time" doesn't mean it is the right thing to do.
Even if it doesn't lead to 20% increase in loading time, if the approach generates lots of error, and we can avoid it, I don't see why we shouldn't.
They're two completely different issues:
1. WoW cliet shouldn't take so long to generate an error log.
2. An addon shouldn't generate any error.
If we can't do anything to prevent this, then there's not much to discuss. But we *can* do something, so why not try to solve *both* problems?
Tell Blizzard to fix (1), *and* we should try to fix (2) on dis-embedded zip packages.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI do think that avoiding the error messages is good style though.
By the way, the client goes over evey single file in WTF and in Addons, passing through all directories even the .svn directories. I think that it keeps this information and uses it as a mask it doesnt appear that it calls the file system driver requesting a file that doesnt exist.
It goes like
1) Get a list of all files
2) Get a list of all Toc's from step 1 (and read them)
3) Character Loading Screen
4) Load Sequence (load toc, then lua's, then sv-luas)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI agree to an extent. But it's not "as simple as that". Ace2 is in a way "abusing" the fact that referring to a file that doesn't exist only gives a warning and not an error. Blizzard has obviously not considered that people would have a need for a more dynamic way of loading addons. However, nothing is set in stone. Blizzard has definitely changed a lot of things about how addons work since the game first came out. Some of those changes have come from community requests, I believe. Wether the Ace2 way of using embedded libraries makes it worth changing something for Blizzard, I have no idea. It all comes down to wanting to make addon loading more dynamic than it is today. That should be the reason to ask for changes if any are needed.
I use Mac so I have no experience with WAU. But if I understand it correctly WAU "moves" embedded libraries out of the addon directories and into the top-level addon directory. If this is the main cause of the problem, then perhaps WAU should also either leave an empty file for each of the libraries being referred in each addon or even better WAU could modify the TOC files and remove the file references.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFin was going to do this once, I'm not sure if he ever finished:
A good experiment would be to read in all the files in an addons directory and concatenate them into one lua, one xml and one toc. What are load times like then? Do they change?