OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000016OMNeT++runtime / Tkenvpublic2008-12-03 14:202008-12-09 15:27
Assigned Toandras 
PlatformOSOS Version
Product Version4.0b8 
Target VersionFixed in Version4.0rc1 
Summary0000016: "fast mode" very slow
DescriptionThe "fast mode" is 0000003:0000010 times slower than in OMNET-3.4b2, TKenv blocks.
TagsNo tags attached.
Attached Filespatch file icon disable-filtering.patch [^] (1,567 bytes) 2008-12-04 16:32 [Show Content]

- Relationships

-  Notes
heep (reporter)
2008-12-03 14:25

10 times slower, blocks frequently for several seconds (2200 messages present -> 50 events/s)
andras (administrator)
2008-12-03 15:46

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.
stkrause (reporter)
2008-12-03 16:23
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.

andras (administrator)
2008-12-03 22:38

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) ?
stkrause (reporter)
2008-12-04 10:08

To blocking: Time based updates should be MUCH better, especially when combined with filtering.

To speed:
- close graphical inspectors: no imprivement
- close object tree: no improvement
- close timeline: no improvement
- disable logging: bingo. Speed increases by a factor of 300.
stkrause (reporter)
2008-12-04 12:04

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)
andras (administrator)
2008-12-04 15:06

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.
andras (administrator)
2008-12-04 16:33

Attached a temporary workaround patch (filtering won't work but simulation will run faster).
andras (administrator)
2008-12-06 09:21

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...
andras (administrator)
2008-12-06 22:52

Found workaround for lousy "delete 1.0 end" performance: need to delete tags from the widget first. Makes it very fast (<<1s).
andras (administrator)
2008-12-09 15:27

Changed Tkenv to use time-based display updates during Fast/Express Run (by default every 500ms and 1000ms, respectively; configurable from the Options dialog)

- Issue History
Date Modified Username Field Change
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 - 2022 MantisBT Team
Powered by Mantis Bugtracker