Thread: Memory hole in chat output?
-
November 25th, 2020, 17:52 #11
Oh, good find on the memory leak in the chat We have a hungry chat seemingly!
My extensions for 3.5e and Pathfinder
Bug reports please here
-
November 25th, 2020, 18:36 #12
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,561
The chat retains 500 chat entries; and every time you need to add an icon, text, die icon, die frame to a chat message, memory will get increased. So, it is expected that memory will increase over time if you are pumping loads of graphics into the chat window that need to be maintained.
Regards,
JPG
-
November 25th, 2020, 19:59 #13
- Join Date
- Aug 2019
- Posts
- 2,025
3.4 gigabytes for 500 chat entries with a total chat.log of 20 mb? Great Scott!
Understood, over and out.
-
November 25th, 2020, 20:46 #14Free(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
-
November 25th, 2020, 21:12 #15
Is there a reason to believe they are related? Being able to cause a memory leak when trying to do so and using the software in a way that no user would normally use doesn't mean they memory leak seen is ever going to be seen in any other situation does it?
I can cause multi-billion dollar software to crash if I want, but since it's not something that ever occurs during normal enterprise use, I don't spend developer time trying to resolve it.
Now, maybe this is indicative of something important. So I repeat the question, is it?
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
November 25th, 2020, 21:20 #16
Don't know how it is here - but coding large complex interrelated software packages that depend on some things that you have written and some things you have not and some 3rd party packages has one common and deadly theme. If you leave something out there that can gobble up your memory either by leak or some sort of open ended coding - it will happen.
I have never allowed something like that to go unaddressed unless I have no unknown things that nobody can duplicate going wrong. And we know, this is not the case here. You investigate and limit anything like that because its like shooting chaff into the air when your trying to locate a bug somewhere. And more often than not - fixing stuff that seem unimportant like that (memory issues) can have radical major good things happen elsewhere. Like mystery bugs that you can't duplicate suddenly going away.
If you live in a software environment where you basically have to ID every possible downstream ramification before you can even address something gobbling memory in the application - legally coded or not - then you live in a different environment than I've ever lived in.
Maybe this is a simpler world than I'm used to. But based on my experience - I would never let that type of thing go. For the reasons I stated. IMHOFree(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
-
November 25th, 2020, 21:30 #17
I get it that it's not desirable to have a known way to cause a memory leak. But remember, limited resources and business implications.
If you have two things you can work on and solve, lets say; a) a possible memory leak that only appears to happen when stress testing the software and their are (so far) no indications that this actually happens in any user use case. Or b) implementing dynamic line of sight that has been clamored over for years by your user base, that many people in your user base complain that if they don't get it immediately they are going to start using a competitor, and even other former customers that have claimed they have left your software to another because your software doesn't have this one feature.
Now, you have a business decision to make. Do you work on A, or B? Because if you pick wrong, it's going to impact your income for the next 12 to 18 months. It's not like the devs work for some big company that is going to pay them regardless. They are only going to get paid, and still have a job, if they make the right decision. So again, A or B?
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
November 25th, 2020, 21:36 #18
You skipped time as if it’s not a factor. This has been isolated - duplicated - and apparently a know part of chat to allow it.
So with context...
A
This is simple to limit.
Time vs potential later pain matters in what you stated above.Free(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
-
November 25th, 2020, 21:42 #19
Ok. Yes, time, I assume you mean time it takes to investigate and resolve? Neither of which we know the amount of effort to solve A or B. We also don't know how much either will actually impact profitability of the software. Both of which issues I assume the developers have a better idea of than we do. Therefore A or B is a valid answer (imo) because we don't know what Doug and John know.
What I do know if that John and Doug have been very successful over the last decade making good business decisions to keep this platform growing, the company growing, and doing things that no other VTT had been able to do before them.
Because of that, I give them the benefit of the doubt. Make them aware of what I think is important or have issue with, etc, and then I trust them to do their job and prioritize what they work on. Hopefully someday they will earn your trust as well.
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
November 25th, 2020, 22:05 #20
- Join Date
- Aug 2019
- Posts
- 2,025
And again we discuss people and personalities instead of the the technical topic at hand.
I did not ask SW to tackle this issue, I just reported it. Frankly, I don't even really care if this is addressed as long as my 16-32 gb machines and high powered CPUs can handle it, others may disagree, though. I literally throw money at the problem and when it still hits me (or more likely my players) I force my group to reload, enduring the moaning and gnashing of teeth until Covid-19 is over or a better solutions comes along. Originally (before Covid-19) I bought FG to assist my GM duties at the physical table-top, I only bought the Ultimate license "just in case" some online sessions might come along.
That being said: I issued a detailed report and reproduction steps + documentation about a possible memory leak, one of the most important and most difficult to identify issues in stable software development. Currently we don't even know if the symptoms reported by me are indeed a memory leak. But don't come at me suggesting that I am only out to waste your time while I provide QA level expertise from outside the blackbox.
Originally Posted by Wikipedia "Memory Leak"
PS: I am not out to break your system. The sole reason for me doing so many die-rolls is to finally get statistical analysis of FG's randomness, an ongoing and ever-returning topic of discussions as it seems to me. You may or may not be interested in the results, but me reporting bugs I stumble over along the way (like the /die maximum bug) has nothing to do with anything else. English is not my native language. Good night.Last edited by Weissrolf; November 25th, 2020 at 22:08.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks