Sean (Jul 20 2020 at 23:38): Sean (Jul 20 2020 at 23:38):@starseeker I know it's not hooked up, but help is the furthest along of libged's new command structure. Please don't merge the deletion.
Sean (Jul 21 2020 at 00:08):(talking about libged/help)
starseeker (Jul 21 2020 at 01:00):@Sean No problem - I only merged the relocations because I figured they were harmless and would make life easier down the road - the bit I'm into now is a bit crazier.
What I'm trying is a bit different from what was there (at least, so far) so I don't know if it will be acceptable in the end or not - it's mostly an experiment, and may end up being a throw-away.
Sean (Jul 21 2020 at 02:52):the relocations aren't a problem, that's been the plan, so it's all good. it's the commit on the branch deleting help/help.cpp that was a lil concerning.
starseeker (Jul 21 2020 at 11:32):@Sean That was a temporary measure for compiling while setting up the change in the API - I should have commented it out rather than deleting it.
starseeker (Jul 21 2020 at 13:08):@Sean fixed - gedplugins branch now has the help and zoom plugins enabled using the new setup.
Sean (Jul 21 2020 at 20:43):cool
Sean (Jul 21 2020 at 20:44):I like them dynamically loading. will be interesting to see how that scales up, what if anything it does to initialization.
Sean (Jul 21 2020 at 20:45):also sets the stage for having a single runner process that dynamically loads and communicates back over a channel -- complete protected process encapsulation
starseeker (Jul 21 2020 at 23:01):/me is being driven slightly batty by the libged file names and function names not necessarily matching the invocation strings higher level code expects, but starting to get some interesting progress now.
Must confess I started down this road trying to see if I could come with a way to avoid all the verbose wrapping logic in the libtclcad layer... figured at the very least it would force me to understand which pieces are doing what.
/me sometimes prefers to trample down the maze rather than wind his way through it...
starseeker (Jul 22 2020 at 01:51):My initialization here (and shutdown) seems to be dominated by Tcl/Tk.
Sean (Jul 22 2020 at 03:22):careful reading into those tea leaves there. it's super i/o heavy, so throwing in a ton of additional syscalls could be exasperating it in ways that won't measure correctly easily.
starseeker (Jul 22 2020 at 21:41):Fair enough - just going by wall clock time. I've notice the same thing with other Tcl/Tk apps on this system (gitk, for example).
Sean (Jul 22 2020 at 21:46):There is a strange stall that seems to happen only sometimes (perhaps tcl index rebuilding, dunno, guessing) that can stall MGED on first launch after install, lasting 20-100 seconds... I haven't been able to reproduce it reliably, but I have seen it.
starseeker (Jul 22 2020 at 21:51):/me nods - seen that too, same symptoms.
starseeker (Jul 22 2020 at 21:52):I think the libged refactor is starting to get interesting. As far as I can tell, I've got MGED and libtclcad working with the new setup.
Sean (Jul 22 2020 at 21:52):I saw, looking good.
Sean (Jul 22 2020 at 21:53):only thought that's come to mind is "I wonder how slow that is" ;)
starseeker (Jul 22 2020 at 21:53):I'll have to try a Windows build next, and maybe toss it on the Github mac runner
starseeker (Jul 22 2020 at 21:53):Um. Do we have benchmarks for that? It shouldn't bother the standard raytracing benchmarks much...
Sean (Jul 22 2020 at 21:53):I had a little test runner I made for indianlarry that I wish I'd kept -- but could probably reproduce
Sean (Jul 22 2020 at 21:54):it timed how fast commands could run, pushed their limit
starseeker (Jul 22 2020 at 21:55):I know it's not a fair question, but if there's any way to know what I need to aim for... How slow is "too slow" in this case?
Sean (Jul 22 2020 at 21:55):if restructuring libged slows down the benchmarks, that enters revert territory because libged shouldn't even be involved :D
Sean (Jul 22 2020 at 21:57):starseeker said:
I know it's not a fair question, but if there's any way to know what I need to aim for... How slow is "too slow" in this case?
I don't think any single command matters unless it gets into non-responsive territory. commands that should complete immediately that are taking 500 to 5000ms for example, when they maybe took 5ms before -- that would be a problem I think
starseeker (Jul 22 2020 at 21:58):Sounds like a candidate for a regression test, actually...
Sean (Jul 22 2020 at 21:59):the general bar for interactivity is 20 per sec, which is 50ms
starseeker (Jul 22 2020 at 21:59):Would need to "normalize" somehow on the platform at the beginning of the run, but if we recorded an expected range based on a ratio of the control test maybe? Even fairly large error bars might be useful for spotting bad problems getting introduced...
Sean (Jul 22 2020 at 22:00):if a command doesn't complete in under that, it's not "interactive". now in practice, I think most people's tolerance is more like web page tolerance, not necessarily interactive rate, but "responsive" enough and that sits in the 2s ballpark.
starseeker (Jul 22 2020 at 22:02):/me gets an idea...
Sean (Jul 22 2020 at 22:03):where a slowdown would be concerning is any commands that call into other commands. like if search suddenly goes from 1s to 10s .. that implies an architecture problem getting introduced.
Sean (Jul 22 2020 at 22:03):I doubt that's happened though
Sean (Jul 22 2020 at 22:05):it'd be nice to have a dashboard of how long each command takes to do its intended function
Sean (Jul 22 2020 at 22:05):which would imply having a test for every command, which we don't have yet though either
starseeker (Jul 22 2020 at 22:11):Well, my libged plugin test is iterating through calling all of them (or should be, at any rate)...
Sean (Jul 22 2020 at 22:12):the mged test calls them all too, to make sure they all report help -- not the same as doing and timing their intended function though
starseeker (Jul 22 2020 at 22:13):Ah. That shouldn't be needed for overhead comparison though, should it? Or is there a chance that living as a shared object will slow down the execution?
Sean (Jul 22 2020 at 22:14):it depends on where slowdown came from
Sean (Jul 22 2020 at 22:15):saw we screwed up rt_db_export_internal performance for example, wouldn't show just by testing usage or help
Sean (Jul 22 2020 at 22:15):they have their place as a test, just not as interesting for dashboarding purposes at least
Sean (Jul 22 2020 at 22:17):and regarding performance for usability testing, startup time is just a fraction of the time that matters
starseeker (Jul 22 2020 at 22:41):@Sean I doubt it's the number you're after, but if it's of interest I added a timer in ged_exec...
Sean (Jul 22 2020 at 22:53):heh, you know you just added another syscall right??
Sean (Jul 22 2020 at 22:54):ah, apparently it depends -- might not be a syscall
Sean (Jul 22 2020 at 22:59):looks like it is a system call, but doesn't always provoke typical system call behavior -- it depends on the OS and libc implementation. may at least avoid an allocation, but may still cause an interrupt/stall.
starseeker (Jul 22 2020 at 23:46):To the overall timing, yes - I thought the issue of main concern was whether the invocation of the ged commands was being slowed?
starseeker (Jul 22 2020 at 23:47):The idea was to show execution times to evaluate whether things look "too slow" or not, and then remove it once it passes muster...
Sean (Jul 22 2020 at 23:47):yes, that was the immediate question. Doesn't need to persist as a feature, though -- just for awareness.
Sean (Jul 22 2020 at 23:47):yeah, thumbs up
starseeker (Jul 22 2020 at 23:48):Ironically, the new approach is a whole lot easier to instrument than traditional ged calls - no single entry point there to watch.
Sean (Jul 22 2020 at 23:48):sure, but that's because you made a ged_exec to call them .. and that's been the plan all along regardless of them being dynamic or not
starseeker (Jul 22 2020 at 23:50):/me nods. So the question is whether they should just all be built as one library in lieu of the individual .so files?
starseeker (Jul 22 2020 at 23:50):/me figured the latter was a good stepping stone to per-process commands (which I would expect to be slower than this approach, really...)
Sean (Jul 22 2020 at 23:50):all or some subset, we may find there's a benefit in having a core guaranteed preloaded
Sean (Jul 22 2020 at 23:50):yep
Sean (Jul 22 2020 at 23:51):per-process will be even more overhead, that's why it's all just situational awareness curiosity. I don't expect it to be much more than a few ms increase.
Sean (Jul 22 2020 at 23:52):if anything, it could conceivably reduce overall runtime while increasing individual commands, because not all have to be resolved by ld during startup
Sean (Jul 22 2020 at 23:55):it should just be adding a few interrupts to do the .so search, open, scan+read the file to get the symbols. that's probably not very much and should only be on the first call.
starseeker (Jul 22 2020 at 23:56):So, bottom line, what's the path forward? I'm not in a tearing hurry to merge - my target is libtclcad and I can tangle with that in this branch well enough - but we'll need some plan to move forward eventually. This'll be a tough to maintain long term as a branch if any significant work starts on libged in trunk...
Sean (Jul 23 2020 at 00:26):if mged seems to be behaving and there's not an obvious slowdown, no major concerns from me.
Sean (Jul 23 2020 at 00:29):if it's slower, that should be born out by observation of an issue (e.g., search 10x slower or something). any fix should be with an eye towards fixing a specific observed problem. i don't think this change warrants hunting for a problem necessarily. a sanity check on a couple typical commands should be enough hopefully, and it'd be good to merge.
starseeker (Jul 23 2020 at 00:50):Sounds good. Time to boot the laptop into Windows again... ugh.
starseeker (Jul 23 2020 at 00:51):/me does the github Mac test first because it's more fun...
Last updated: Jan 09 2025 at 00:46 UTC