The Fix
First off, the localization; that's quite easy to explain I think. WoW already parses the .toc file with a bit more intelligence than was originally intended, I suggest a new "#" line that loads a file only for the specified locale, like "#enUS: MyLocaleStringsENUS.lua". This will help. A lot.
The harder part are libraries, my base idea is to interpret libraries as addons. I know you can already do this, but it's not useful. Users are getting confused when they have to move folders around; also having all libraries in the addon listing would make it quite long.
Instead I suggest that not only the /Interface/Addons folder should be parsed for libraries but also its subfolders.
There are various ways to achieve this, but the best I think would be to define a special named folder inside and addon folder that will be searched for libraries (addons) by wow, like "Libraries" or something like that. Since all those will be just like addons, they have an own .toc. With all the features of it. LoadOnDemand, the locale suggestion from above, etc.
I find this moot unless you can get Blizzard to even listen to your ideas as all of this is changing how the client loads addons. Nothing we as authors can do to even test out your theories. Somehow need to open the dialog with Blizzard or we are wasting our time even considering what this would mean.
I find this moot unless you can get Blizzard to even listen to your ideas as all of this is changing how the client loads addons. Nothing we as authors can do to even test out your theories. Somehow need to open the dialog with Blizzard or we are wasting our time even considering what this would mean.
That of course is the whole point of it - get support for the suggestion and get it ready to suggest it to blizzard. (guess that point is lost though...)
I thought other authors would like the idea of load on demand libraries too, or the prospect a dynamic number of libraries neatly packed in an addon folder without having to use possibly malevolent shell or batch scripts to extract them afterward.
I wasn't sure if I should stress the point of easier addon and library handling in the suggestion since it's of no use at all for blizzard, but reduced loading time helps them for sure. Whether they find it important enough to assign some programmers to it, I don't know but I thought that would be more likely than for addon author convenience.
If you don't ask for it however, you'll never know if you could have gotten it.
Whether they find it important enough to assign some programmers to it, I don't know but I thought that would be more likely than for addon author convenience.
I think that lot of us would rather they devote the programers for new API's and improvements ingame than a convinice that we could program around and users can just live with and not kill them :D
My previous post was an official warning from me, as a moderator, to watch your tone. If you want to discuss the topic you created this thread to discuss, please continue to do so in a calm and reasoned manner, while keeping in mind that multiple people are interpreting your posts as overly aggressive. If you wish to discuss yourself further, feel free to do so in PMs.
That of course is the whole point of it - get support for the suggestion and get it ready to suggest it to blizzard. (guess that point is lost though...)
I thought other authors would like the idea of load on demand libraries too, or the prospect a dynamic number of libraries neatly packed in an addon folder without having to use possibly malevolent shell or batch scripts to extract them afterward.
I wasn't sure if I should stress the point of easier addon and library handling in the suggestion since it's of no use at all for blizzard, but reduced loading time helps them for sure. Whether they find it important enough to assign some programmers to it, I don't know but I thought that would be more likely than for addon author convenience.
If you don't ask for it however, you'll never know if you could have gotten it.
I'll like to throw in a point for you to ponder. In the past, there has been such suggestions and attempts before, to implement a better method of loading addons and submodules (that is, submodules that can exist as a subaddon, rather than at the main addon level), which is somewhat related to having a library folder of addons.
Blizzard has never responded to such requests on their UI forum, but I'm sure they have read such suggestions. My interpretation is that they have such things on extremely low priority (we already have a working addon system), when compared to fixing existing bugs, and introducing major features like combat log revamp, new threat API, addon messages, guild banks, etc.
The real solution to the file loading problem for localization is really to put ALL localization data into ONE file instead of eight files. The operating system can load the entire file (say 40 kb) with a block load at about the same speed as opening one localization file (say 5 kb). So localization data should be in huge if-then-elseif-then-elseif-then constructs. Less files is good.
Authors should get rid of embeds.xml (not used by packager anymore) and locales.xml and just put the whole thing into the TOC directly and use the new #@no-lib-strip@ and #@end-no-lib-strip@ features provided by wowace/curseforge's packager. Admittedly, loadtime is increased by having libraries provide its own lib.xml to be referenced to load itself when embedded, but this easily allows libraries to add internal files without requiring all addons that use it to modify their embeds.xml/toc.
Parsing and compiling bytecode uses a neligible amount of time compared to file I/O and shouldn't really have to be considered. To this effect, you can easily test this out by loading 1000 identical small files and then loading 1 file containing 1000 copies of the same code.
We have done testing before with a 20 MB savedvariable, 10 MB of which is just comments at the end of every line "-- [1] blah blah", compared to stripping out those comments (ever seen Lootlink's or Auctioneer's savedvariable file contents?). The result is that parsing it gives negligible time, it was the file I/O that was loading the 20 mb vs 10 mb (you can't block load that much from the disk). You can test this because ADDON_LOADED fires just after the SavedVariables for your addon have loaded, but you can record GetTime() in your addon's main chunk and check with OS level timings (Test was done by cladhaire informally on IRC.)
AddonLoader is an addon that is created to delay loading of addons as a LoadManager by making addons LoD, and loading them only when certain events happen. For example, Postal when used with AddonLoader, will only load when you visit a mailbox.
-----
Oh, and I'll also back Phanx up that your responses have been overly aggressive. I do however want to contribute to the discussion instead of ending it with a thread lock.
In the end, Reducing load times is going to net the end user absoloutely nothing. The only reason people bitch about load times is the crack addiction they have to wow.
This.
I run my addons with 100% disembedded libraries, including LibStub, CallbackHandler-1.0, LibDataBroker-1.1, and all the other "embedded only" libraries. I remove unused localization files and remove all references to them in .toc and .xml files (although usually I remove the .xml files too). I update my addons "by hand".
What does all of this extra effort do for me? It reduces my loading time by about 50%. Does it really make or break anything if my game loads in 20 seconds instead of 40 seconds? I'd say no. I do it anyway because the idea of having 100 copies of each library on my hard drive annoys the crap out of me, and it does have a tangible performance benefit, albeit one that doesn't really have any impact on my actual gameplay.
Does Blizzard have any incentive whatsoever to change the way the game loads addons? Again, I'd say no. Users can already achieve the end result of your proposal by doing what I do. Authors could, in theory, facilitate this achievement by a) not using any libraries and b) packaging separate downloads for each locale or other variant. Third parties could also facilitate this achievement by developing more intelligent addon management software that would automatically remove unused locales, duplicate libraries, and remove references to nonexistent files. Given that all of these options exist and are quite possible with the system as it is today, I really don't see Blizzad having any interest in spending time and money developing and testing the changes in their software you're proposing.
The real solution to the file loading problem for localization is really to put ALL localization data into ONE file instead of eight files. The operating system can load the entire file (say 40 kb) with a block load at about the same speed as opening one localization file (say 5 kb). So localization data should be in huge if-then-elseif-then-elseif-then constructs. Less files is good.
I didn't know that... one of these days I'll find time to learn about the inner workings of the computer. Either that or finish my comp sci degree. I'm not sure which one is likely to happen sooner. :p
I didn't know that... one of these days I'll find time to learn about the inner workings of the computer. Either that or finish my comp sci degree. I'm not sure which one is likely to happen sooner. :p
It's not healthy for localizers though, because they cannot compare 2 files side by side with line numbers to see if they have localized every string. And some of our addons DO have over 300+ strings hehe. The one-file localization idea has been used in many places though, key examples are in libraries where making everything fast is a primary objective, such as in StatLogic-1.0, LibFuBarPlugin-3.0, and many of the Ace2 libraries.
There are plenty of ways to optimize your load times, trust me I'm about the most anal about that around here. In the end, the thing I've found has had the greatest impact? AddonLoader. Use it for EVERYTHING YOU CAN. Mass majority of my addons are on the delayed load. They still load every login, but I'm in and playing before time is spent loading them. I've never found that I *needed* anything I have set on delayed in the first few minutes I'm in-game.
Delay loading as long as you can, and you'll be damn happy.
There are plenty of ways to optimize your load times, trust me I'm about the most anal about that around here. In the end, the thing I've found has had the greatest impact? AddonLoader. Use it for EVERYTHING YOU CAN. Mass majority of my addons are on the delayed load. They still load every login, but I'm in and playing before time is spent loading them. I've never found that I *needed* anything I have set on delayed in the first few minutes I'm in-game.
Delay loading as long as you can, and you'll be damn happy.
Delayed loading of addons causes some issues though (only in 3.0.2). Primarily, some addons have optional dependencies, say addonA specifies addonB as an optdep, and thus in the initialization routine of addonA, it checks to see if addonB is present. If B isn't present because it was delay-loaded by AddonLoader, then A will lose B's addition functionality, and this the work around would only be for A to add an ADDON_LOADED event check.
This has indeed caused issues for me with in Routes because it has optional dependencies on all its data sources, and GatherMate was delay-loaded through AddOnLoader. This wasn't an issue pre-3.0.2 because an optdep is forced to load for another addon even if a LoadManager was specified, but 3.0.2 broke it.
I've heard about these issues, yet I've not run into them myself. 3.0.3 will clear all that up, so it seems a minor issue at best :P
Even before 3.0.2, Squeenix does weird shit unless you're using AddonLoader. Zone text disappears, and a few other things I can't think of at the moment.
Clearly solution is:
1: Get a job
2: Spend the amount of time you would have spent optimizing your addon folder earning money
3: Buy a new fast hard drive.
Raptor harddisks (10000 RPM) are noisy though, and cost 4x or 5x as much when you consider the Gb per dollar ratio. SeaGate harddisks are the quietest, good for home users, and still spin at 7200 RPM!
I love how disk drives never list sustained transfer.
Now those SSD drives, they can get 150MB/s read and 75-100MB/s write sustained speeds farily easily. 16GB drives are under $200 these days, that's more than enough to run WoW on. I'll probably get me one when I have the money, but I just blew $340 on mobo/proc/mem/vid :P
I love how disk drives never list sustained transfer.
Now those SSD drives, they can get 150MB/s read and 75-100MB/s write sustained speeds farily easily. 16GB drives are under $200 these days, that's more than enough to run WoW on. I'll probably get me one when I have the money, but I just blew $340 on mobo/proc/mem/vid :P
You would indeed be able to run WoW on a 16 GB SSD drive.... but you won't be able to patch it without first moving/copying it on another drive with more empty space. :D
Wrath is 15 GB in size hehe.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I find this moot unless you can get Blizzard to even listen to your ideas as all of this is changing how the client loads addons. Nothing we as authors can do to even test out your theories. Somehow need to open the dialog with Blizzard or we are wasting our time even considering what this would mean.
That of course is the whole point of it - get support for the suggestion and get it ready to suggest it to blizzard. (guess that point is lost though...)
I thought other authors would like the idea of load on demand libraries too, or the prospect a dynamic number of libraries neatly packed in an addon folder without having to use possibly malevolent shell or batch scripts to extract them afterward.
I wasn't sure if I should stress the point of easier addon and library handling in the suggestion since it's of no use at all for blizzard, but reduced loading time helps them for sure. Whether they find it important enough to assign some programmers to it, I don't know but I thought that would be more likely than for addon author convenience.
If you don't ask for it however, you'll never know if you could have gotten it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think that lot of us would rather they devote the programers for new API's and improvements ingame than a convinice that we could program around and users can just live with and not kill them :D
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'll like to throw in a point for you to ponder. In the past, there has been such suggestions and attempts before, to implement a better method of loading addons and submodules (that is, submodules that can exist as a subaddon, rather than at the main addon level), which is somewhat related to having a library folder of addons.
Blizzard has never responded to such requests on their UI forum, but I'm sure they have read such suggestions. My interpretation is that they have such things on extremely low priority (we already have a working addon system), when compared to fixing existing bugs, and introducing major features like combat log revamp, new threat API, addon messages, guild banks, etc.
The real solution to the file loading problem for localization is really to put ALL localization data into ONE file instead of eight files. The operating system can load the entire file (say 40 kb) with a block load at about the same speed as opening one localization file (say 5 kb). So localization data should be in huge if-then-elseif-then-elseif-then constructs. Less files is good.
Authors should get rid of embeds.xml (not used by packager anymore) and locales.xml and just put the whole thing into the TOC directly and use the new #@no-lib-strip@ and #@end-no-lib-strip@ features provided by wowace/curseforge's packager. Admittedly, loadtime is increased by having libraries provide its own lib.xml to be referenced to load itself when embedded, but this easily allows libraries to add internal files without requiring all addons that use it to modify their embeds.xml/toc.
Parsing and compiling bytecode uses a neligible amount of time compared to file I/O and shouldn't really have to be considered. To this effect, you can easily test this out by loading 1000 identical small files and then loading 1 file containing 1000 copies of the same code.
We have done testing before with a 20 MB savedvariable, 10 MB of which is just comments at the end of every line "-- [1] blah blah", compared to stripping out those comments (ever seen Lootlink's or Auctioneer's savedvariable file contents?). The result is that parsing it gives negligible time, it was the file I/O that was loading the 20 mb vs 10 mb (you can't block load that much from the disk). You can test this because ADDON_LOADED fires just after the SavedVariables for your addon have loaded, but you can record GetTime() in your addon's main chunk and check with OS level timings (Test was done by cladhaire informally on IRC.)
AddonLoader is an addon that is created to delay loading of addons as a LoadManager by making addons LoD, and loading them only when certain events happen. For example, Postal when used with AddonLoader, will only load when you visit a mailbox.
-----
Oh, and I'll also back Phanx up that your responses have been overly aggressive. I do however want to contribute to the discussion instead of ending it with a thread lock.
This.
I run my addons with 100% disembedded libraries, including LibStub, CallbackHandler-1.0, LibDataBroker-1.1, and all the other "embedded only" libraries. I remove unused localization files and remove all references to them in .toc and .xml files (although usually I remove the .xml files too). I update my addons "by hand".
What does all of this extra effort do for me? It reduces my loading time by about 50%. Does it really make or break anything if my game loads in 20 seconds instead of 40 seconds? I'd say no. I do it anyway because the idea of having 100 copies of each library on my hard drive annoys the crap out of me, and it does have a tangible performance benefit, albeit one that doesn't really have any impact on my actual gameplay.
Does Blizzard have any incentive whatsoever to change the way the game loads addons? Again, I'd say no. Users can already achieve the end result of your proposal by doing what I do. Authors could, in theory, facilitate this achievement by a) not using any libraries and b) packaging separate downloads for each locale or other variant. Third parties could also facilitate this achievement by developing more intelligent addon management software that would automatically remove unused locales, duplicate libraries, and remove references to nonexistent files. Given that all of these options exist and are quite possible with the system as it is today, I really don't see Blizzad having any interest in spending time and money developing and testing the changes in their software you're proposing.
I didn't know that... one of these days I'll find time to learn about the inner workings of the computer. Either that or finish my comp sci degree. I'm not sure which one is likely to happen sooner. :p
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's not healthy for localizers though, because they cannot compare 2 files side by side with line numbers to see if they have localized every string. And some of our addons DO have over 300+ strings hehe. The one-file localization idea has been used in many places though, key examples are in libraries where making everything fast is a primary objective, such as in StatLogic-1.0, LibFuBarPlugin-3.0, and many of the Ace2 libraries.
Delay loading as long as you can, and you'll be damn happy.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDelayed loading of addons causes some issues though (only in 3.0.2). Primarily, some addons have optional dependencies, say addonA specifies addonB as an optdep, and thus in the initialization routine of addonA, it checks to see if addonB is present. If B isn't present because it was delay-loaded by AddonLoader, then A will lose B's addition functionality, and this the work around would only be for A to add an ADDON_LOADED event check.
This has indeed caused issues for me with in Routes because it has optional dependencies on all its data sources, and GatherMate was delay-loaded through AddOnLoader. This wasn't an issue pre-3.0.2 because an optdep is forced to load for another addon even if a LoadManager was specified, but 3.0.2 broke it.
3.0.3 better come soon...
-
View User Profile
-
View Posts
-
Send Message
Project AuthorEven before 3.0.2, Squeenix does weird shit unless you're using AddonLoader. Zone text disappears, and a few other things I can't think of at the moment.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium1: Get a job
2: Spend the amount of time you would have spent optimizing your addon folder earning money
3: Buy a new fast hard drive.
Example:
http://www.wdc.com/en/products/products.asp?driveid=494&language=en
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNow those SSD drives, they can get 150MB/s read and 75-100MB/s write sustained speeds farily easily. 16GB drives are under $200 these days, that's more than enough to run WoW on. I'll probably get me one when I have the money, but I just blew $340 on mobo/proc/mem/vid :P
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou would indeed be able to run WoW on a 16 GB SSD drive.... but you won't be able to patch it without first moving/copying it on another drive with more empty space. :D
Wrath is 15 GB in size hehe.