Blank Profile Procs

ID:82291
 
Sep 19 2009, 10:15 pm
Resolved
Init procs created by compile-time initializations (e.g., turf/var/badwaytomakealist[0]) now have names that will show up in the profiler, instead of being blank. The names are in the form [path]/proc/(init).
BYOND Version:454
Operating System:Windows Vista Home Premium
Web Browser:Firefox 3.0.14
Applies to:DM Language
Status: Resolved (509.1305)
This issue has been resolved.


What are these? I usually have multiple instances of them on the list, but they're usually not the highest thing on the CPU usage sort
Sep 19 2009, 10:30 pm (Edited on Sep 19 2009, 11:02 pm)
OK, that one seems to be from list()
Sep 19 2009, 10:35 pm (Edited on Sep 19 2009, 11:02 pm)
On a mostly unrelated note: The new check-box for "Could this issue affect security?" should be something more like "This issue could affect security"
Sep 20 2009, 7:43 am
If you have more information (like as you say, this seems to come from list()), can you post any related info or code? Right now there's absolutely nothing that can be tested for a bug report.
Sep 20 2009, 10:42 am (Edited on Sep 20 2009, 10:57 am)
Run > Profile > Reboot - Should show a blank proc:
mob/var/list/L=list()

In my case I had it assigned as an atom var; which made some epic lag at start up (more like a delay before start up really) and defining 5 new lists for all atoms in this way prevented the world from even starting up.
In my current project, and pretty much all of my other projects, I have several other blank procs showing on the profiler, but I'm not sure what they're coming from. They use minimal CPU though, so I'm not too worried about them.
Sep 20 2009, 2:31 pm
Okay, this actually turns out not to be so much a bug then. This unnamed proc is created as part of the fact that a list is assigned to a mob var at compile-time. This is related to the problem that initial() doesn't work with vars like this. Assigning a name to the proc might be preferable, or perhaps showing it as /mob/var/L if possible. This is probably more of a feature request than a bug, but I think it probably makes more sense to leave it on the bug list and defer it.
Oct 24 2009, 7:26 pm
mob/M in get_step(src,src.dir)

I get it while using the above code.
I usually use it in the format of...
mob/verb/attack(mob/M in get_step(src,src.dir)) //...

Yet, every time I use it no matter if there is a mob in front of me or not, it adds 2 calls to the blank proc.
Sep 1 2014, 7:36 am
Originally reported by Mav472.

Descriptive Problem Summary:
See http://oi62.tinypic.com/10h3mtu.jpg for an example. The profiler shows that something is taking a long time, but doesn't specify what that something is.

Mav472 wrote:
>I tried using set waitfor = 0 and replacing spawn with sleep but the procs still came up blank.
This needs to be fixed.

Sources:
id:1670738
id:1671009

Expected Results:
The profiler should always show what the cause of a problem is.

Actual Results:
Blank results can show up, which are nearly impossible to diagnose.
Sep 1 2014, 8:18 am
In response to Sir Lazarus
Regardless of the cause I still think it's a bug. The profiler must always point to the cause, not confuse us with blank lines.

Could the profiler be extended by showing the file and line number where the offending code begins? This would resolve any problem with blank lines and add a useful feature.
Sep 1 2014, 9:35 am
In response to Sir Lazarus
I read somewhere that global variable initialization also takes place in unnamed functions.
Sep 1 2014, 12:56 pm
Descriptive Problem Summary:
This picture should explain itself.
http://oi62.tinypic.com/10h3mtu.jpg


Numbered Steps to Reproduce Problem:
I tried using set waitfor = 0 and replacing spawn with sleep but the procs still came up blank.
This needs to be fixed.


Sep 1 2014, 2:40 pm
Once the world is done loading and the game starts up, most of those blank procs in the picture above aren't blank anymore except for the first one eating up all the cpu. Obviously the problem is at the world startup but could this possibly be associated with the creation of certain turfs or objects on the map? I disabled the world map (the biggest one out of 4) and came up with this result. http://oi62.tinypic.com/oksswk.jpg
Jan 15 2015, 9:44 pm
Descriptive Problem Summary:
Profiling is showing null procs when the server is live.
Numbered Steps to Reproduce Problem:This is eally hard to produce, but when the server is hosted live and I reboot, given that I start profiling fsat enough I see the problem. Tons of CPU use, weird negative numbers etc. But It doesnt lag. It's just a concern. When I update, I upload the new .dmb and .rsc to shells server then reboot from game.

Problem Screenshothttp://gyazo.com/975b1e800bc2b0a940a73a95bdfd5576
Expected Results:
Procs are defined
Actual Results:
Procs show up as null and use unreal amount of CPU over unreal amount of time.


Jan 16 2015, 12:18 am
In response to Sir Lazarus
Sir Lazarus wrote:
Could the profiler be extended by showing the file and line number where the offending code begins? This would resolve any problem with blank lines and add a useful feature.

Oh that would be amazing..
If actually implemented one day, rather than in 5 years to never..

Apr 2 2015, 9:08 am
How is this bug Still not fixed? and We need more functions for the profiler. Please fix this.!
Apr 2 2015, 10:52 am
I know what causes this now and it's not entirely a bug. It's not desirable either, but I don't have an immediate solution for it and it's been fairly low-priority.

Here's what's happening: When you initialize vars at compile-time instead of at runtime, of the type that would require a proc to run (e.g., like creating a list), a hidden "init" proc is created for that type. Any of these will cause an init proc to be created:

mob/anyoldtype
    // All of these require an object to be created, so a hidden init proc is built to create them.
    var/mylist[0]
    var/mylist2 = list()
    var/milist3 = newlist(/obj)
    var/obj/hammer/hammer = new

Ultimately what I should do is find a way to tell if a proc is an init proc, and if so for which type (I'm not sure if it has that info), and spit out the info in the profiler.

Bear in mind, init procs are something you should avoid if you can--especially if they belong to turfs, or anything on the map. Such things end up causing long delays on startup. It's best if you don't instantiate any datums or lists until you need them.
Apr 28 2015, 11:40 am
In response to Lummox JR
I think this would be easier to avoid if world/New() was the first proc that ran on world startup. I was putting effort into avoiding blank procs until I realized it's difficult with objects initializing before the world. (I'm actually wondering why this is the order of things - wouldn't it make more sense for the world to fully load before initializing its contents?)

It's not that big a deal though, just putting that out there.
Oct 9 2015, 1:03 pm
Lummox JR resolved issue with message:
Init procs created by compile-time initializations (e.g., turf/var/badwaytomakealist[0]) now have names that will show up in the profiler, instead of being blank. The names are in the form [path]/proc/(init).
Oct 10 2015, 10:03 am
Awesome!
Oct 10 2015, 9:03 pm
This is wonderful, thank you!