|Anonymous | Login||2019-12-08 16:00 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000016||OMNeT++||runtime / Tkenv||public||2008-12-03 14:20||2008-12-09 15:27|
|Target Version||Fixed in Version||4.0rc1|
|Summary||0000016: "fast mode" very slow|
|Description||The "fast mode" is 0000003:0000010 times slower than in OMNET-3.4b2, TKenv blocks.|
|Tags||No tags attached.|
|Attached Files||disable-filtering.patch [^] (1,567 bytes) 2008-12-04 16:32 [Show Content]|
|10 times slower, blocks frequently for several seconds (2200 messages present -> 50 events/s)|
Could you be a little more specific? What kind of simulation? Is it possible that eventlog recording is turned ON in 4.0, or you're recording a lot more data into output vectors than with 3.4b2?
Blocks frequently for several seconds: that's because the output vector manager keeps data buffered, and writes them out in large chunks (that's when the blocking occurs). This is normal behaviour.
edited on: 2008-12-03 16:42
We're doing OverSim-Quon simulations. Eventlog recourding is turned off. The simulation is exactly the same, so we are not recording more data. Also, "frequently blocking" means "almost the whole time", i.e. every time I click a button it takes several seconds until omnet reacts. This does not happen in "normal" or "express" mode.
The speed problem seems to connect to the number of lines in the scrollback buffer, as the simulation speed decreses (quickly) after switching from express to fast at any given point in the simulation. Scrollback buffer size is 100k, in omnet4 as well as omnet3.
The blocking problem seems to be that omnet only refreshes when it displays a string in the output window. If you filter the output to only display the output of a module that produces no output, omnet will stay frozen.
OK I know what frequent blocking means: Tkenv processes UI messages every x simulation events; this x can be changed in the Simulation Options dialog -> General tab -> Update Freq. If you have 50 ev/s, then Update Freq should be <50... (Note: maybe it would be better to make it time based, not event number based.)
How does event/sec change when you turn off UI features one by one, that is:
- close graphical inspectors,
- hide object tree in the main window (using toolbar icon),
- hide timeline,
- disable logging into the main window (Sim.Options->General->top checkbox) ?
To blocking: Time based updates should be MUCH better, especially when combined with filtering.
- close graphical inspectors: no imprivement
- close object tree: no improvement
- close timeline: no improvement
- disable logging: bingo. Speed increases by a factor of 300.
|A quick valgrind shows the problem may be related to the use of elide (0000017:0000057) in the main window: Most of the runtime was spend in "TkTextIsElided" and "TkBTreeGetTags" (even when not filtering output at all)|
|Yep. Looks like the tagging feature of the Tk text widget (see bug 0000017) doesn't scale to having hundres of tags... (Currently every module ID is used as a tag.) I'll investigate doing the filtering in another way.|
|Attached a temporary workaround patch (filtering won't work but simulation will run faster).|
I reimplemented filtering in another way. Now I store the log messages in the memory myself, and on closing the filter dialog I re-fill the text widget with manually filtered contents. This fixes strange scrolling behavior (0000017) as well.
New feature that came as side effect from storing the log: when you open a per-module output window, it comes up containing previous messages (and not empty as it used to).
Current issue: Tk takes its time to clear existing window contents, i.e. ".main.text delete 1.0 end" takes forever. Destroying and re-creating the widget would be instantaneous, but very cumbersome to implement...
|Found workaround for lousy "delete 1.0 end" performance: need to delete tags from the widget first. Makes it very fast (<<1s).|
|Changed Tkenv to use time-based display updates during Fast/Express Run (by default every 500ms and 1000ms, respectively; configurable from the Options dialog)|
|2008-12-03 14:20||heep||New Issue|
|2008-12-03 14:25||heep||Note Added: 0000048|
|2008-12-03 15:46||andras||Note Added: 0000051|
|2008-12-03 16:23||stkrause||Note Added: 0000052|
|2008-12-03 16:42||stkrause||Note Edited: 0000052|
|2008-12-03 22:38||andras||Note Added: 0000054|
|2008-12-04 10:08||stkrause||Note Added: 0000055|
|2008-12-04 12:04||stkrause||Note Added: 0000058|
|2008-12-04 15:06||andras||Note Added: 0000061|
|2008-12-04 16:32||andras||File Added: disable-filtering.patch|
|2008-12-04 16:33||andras||Note Added: 0000062|
|2008-12-06 09:21||andras||Note Added: 0000067|
|2008-12-06 09:21||andras||Status||new => resolved|
|2008-12-06 09:21||andras||Fixed in Version||=> 4.0rc1|
|2008-12-06 09:21||andras||Resolution||open => fixed|
|2008-12-06 09:21||andras||Assigned To||=> andras|
|2008-12-06 22:52||andras||Note Added: 0000071|
|2008-12-09 15:27||andras||Note Added: 0000084|
|Copyright © 2000 - 2019 MantisBT Team|