Community
Participate
Working Groups
From bug 335027 comment #37: > (In reply to comment #35) > > Poor display of 1000 threads > > As I mentioned in the conf call a while back, we don't normally > have to worry about that case, because having a gazillion > threads on the same core is usually not an effective use > of processor resources. One should be using a master/worker > pattern, or thread pooling, etc. so that ideally one or at most > a few threads are running on each core. > > This hasn't come up as an issue for the Grid View because > developers tend to be savvy about multicore design, but > you're right that people running generic code in the visualizer > are more likely to try "let see if it goes to eleven" > kinds of programs, which would raise these kinds of issues. > > We can modify the visualizer so that if more than > a displayable number of threads are on a given core, we only draw > a few, then a "..." indication, or otherwise indicate there are > "An Awful Lot of Threads Here". (In a tooltip, or other mechanism, > we can show the individual thread IDs, if the list isn't > ridiculously long, and if it is, we use "..." again.) > > I wouldn't go overboard trying to squeeze in lots of threads, > because as noted above, this case should be the exception > rather than the rule. (And in fact, having a lot of threads > crowded on one tile is a good visual indicator of imbalanced > code, so you don't _want_ it to look too neat and tidy! :-)
