Click here to Skip to main content
15,904,351 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life but is not for programming questions. Got a programming question?

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.

 
GeneralRe: In .NET enumeration is slow Pin
obermd19-Jan-24 3:44
obermd19-Jan-24 3:44 
GeneralRe: In .NET enumeration is slow Pin
trønderen19-Jan-24 5:44
trønderen19-Jan-24 5:44 
QuestionRe: In .NET enumeration is slow Pin
Eddy Vluggen18-Jan-24 15:54
professionalEddy Vluggen18-Jan-24 15:54 
GeneralRe: In .NET enumeration is slow Pin
englebart19-Jan-24 15:33
professionalenglebart19-Jan-24 15:33 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch19-Jan-24 16:07
mvahoney the codewitch19-Jan-24 16:07 
GeneralRe: In .NET enumeration is slow Pin
trønderen20-Jan-24 6:38
trønderen20-Jan-24 6:38 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch20-Jan-24 7:19
mvahoney the codewitch20-Jan-24 7:19 
GeneralRe: In .NET enumeration is slow Pin
trønderen20-Jan-24 8:28
trønderen20-Jan-24 8:28 
If you do buddy with a set of freelist heads, one for each size, and your buddy combiner orders the freelist, you have an extra benefit of locality: most accesses would go to the lower end of the heap, making better use of virtual memory (less paging).

A background GC could unhook a freelist (maybe leaving a couple entries in the list for use while the GC was working), returning with one shorter list for the original freelist and one list of combined buddies to be put into the next higher size freelist.

The head end of the freelist may be rather unordered - this is where all the allocation and freeing is taking place. If the list is long - it hasn't been emptied for quite some time - the tail end may be perfectly sorted after the previous GC/combination round. If you do sorting e.g. by Smoothsort, handling the already sorted part has complexity O(n), so most likely, the long freelist will not required much effort.

You find buddies by traversing a sorted list, so the list of buddy pairs will also be sorted. If the next higher freelist is also mostly sorted, all buddy pairs is inserted into this is list in a single traversal.

I would do real timing tests with a synthetic heap load (modeled after a relevant usage scenario) to see if it really is worthwhile the resource cost of an asynchronous GC thread - strongly suspecting that a finely tuned incremental but synchronous buddy manager can do it both at a lower total resource cost and with so small delays that it would be a much better solution.

Final remark:
"you've finished doing useful work and you don't need to make the user wait for the collection". In most systems, each process has its own heap. Multiple processes allocating from one common global heap requires a lot of resource consuming synchronization. Most CLI programs are run in their own processes. So when they complete, noone cares about what their heap looks like at that time. There is no reason to do any garbage collection at that time. The entire data segment holding the heap is released en bloc.

In an embedded system, you often have a single systemwide heap. But few embedded system have CLI interfaces for running arbitrary programs that start up and terminate as a function of user operations. Even if the embedded system has some sort of UI, user actions are usually limited to activating specific built-in operations in the embedded code, not separate CLI oriented programs. But of course, there may be exceptions Smile | :)

Religious freedom is the freedom to say that two plus two make five.

GeneralRe: In .NET enumeration is slow Pin
PIEBALDconsult18-Jan-24 9:53
mvePIEBALDconsult18-Jan-24 9:53 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 9:55
mvahoney the codewitch18-Jan-24 9:55 
GeneralRe: In .NET enumeration is slow Pin
Eddy Vluggen18-Jan-24 15:17
professionalEddy Vluggen18-Jan-24 15:17 
GeneralRe: In .NET enumeration is slow Pin
Dave Kreskowiak18-Jan-24 11:09
mveDave Kreskowiak18-Jan-24 11:09 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 11:21
mvahoney the codewitch18-Jan-24 11:21 
GeneralRe: In .NET enumeration is slow Pin
PIEBALDconsult18-Jan-24 11:34
mvePIEBALDconsult18-Jan-24 11:34 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 11:48
mvahoney the codewitch18-Jan-24 11:48 
GeneralRe: In .NET enumeration is slow Pin
Eddy Vluggen18-Jan-24 15:19
professionalEddy Vluggen18-Jan-24 15:19 
GeneralRe: In .NET enumeration is slow Pin
Kenneth Haugland18-Jan-24 11:30
mvaKenneth Haugland18-Jan-24 11:30 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 11:43
mvahoney the codewitch18-Jan-24 11:43 
GeneralRe: In .NET enumeration is slow Pin
Gerry Schmitz18-Jan-24 11:50
mveGerry Schmitz18-Jan-24 11:50 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 12:04
mvahoney the codewitch18-Jan-24 12:04 
GeneralRe: In .NET enumeration is slow Pin
Graeme_Grant18-Jan-24 12:02
mvaGraeme_Grant18-Jan-24 12:02 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 12:05
mvahoney the codewitch18-Jan-24 12:05 
GeneralRe: In .NET enumeration is slow Pin
Graeme_Grant18-Jan-24 12:08
mvaGraeme_Grant18-Jan-24 12:08 
GeneralRe: In .NET enumeration is slow Pin
Richard Andrew x6418-Jan-24 12:21
professionalRichard Andrew x6418-Jan-24 12:21 
GeneralRe: In .NET enumeration is slow Pin
honey the codewitch18-Jan-24 12:42
mvahoney the codewitch18-Jan-24 12:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.