currently, one .NET process shares one GC. making as program gets bigger, cost of GC gets worse and worse and there is no clear way to avoid this problem. most of time, due to this issue, people creates outer proc just to avoid GC cost when doing big analysis or allocation heavy operations. and remote data between these two processes.

please, make better solution and this. explicitly moving data between processes are pain in the ***. this problem basically makes .NET only for small apps. but not for serious apps.

...

one solution I can think of to mitigate this problem is ,instead of this, create a local GC concept, that auto-matically tracks whether a object lives inside of the local GC or references/referenced by objects lives outside of the local GC. and if it references/referenced objects lives outside, promote it to the master GC (the current GC that freeze everyone).

I believe this local GC concept + existing generation GC will reduce time each GC run which ends up making GC cheaper (less object graph to track on each GC) because on top of existing allocation based policy, we now have context.

most of time, when app runs, it runs things in isolation and only small set of objects are actually shared, most of others stays inside of this isolation from the creation to the end.

this is especially true as app going more and more concurrent and immutable.

two features run parallel in different threads sharing GC is a good example since an allocation that should be considered short live now might become gen 1 or gen 2 objects because a features runs in other threads do a lot of allocations.

please, do something to make GC cheaper (how cheaper, please make me never notice GC running when I run very plain, normal big apps such as VS or Roslyn)

There is an important impedance mismatch between the generated API for F# clients and for other CIL clients (such as C#):

[<AbstractClass>]
type Base internal() = class end

Seen from an external F# client, the above constructor is internal (i.e., not accessible), as it should be. However, seen from any other CIL client (like C#), the above constructur is protected.

In order to truly hide the F# ctor from any CIL client, one is forced to make the F# class concrete instead of abstract. This workaround is ugly, but acceptable. However, the fact that I have to use the workaround is *too esoteric* to be known to most developers. As a consequence, there is a high risk of design flaws creeping into in F# projects who will be integrated into a overall domain model of a mixed C#/F# solution.

(There are other, less significant impedance mismatches, such as F# private members becoming visible to non-F# clients via [<InternalsVisibleTo>]. However, please be aware that seamless integration with other CIL languages is of crucial importance for the continuing success of F#. I am speaking from the perspective of a big, real-world ERP solution we are creating right now).

I'd rather put my classes under version control than sourcefiles. Sourcefiles that contain one or more classes that should be taken under source control should get parsed and only the classes itself should be versioned, The sourcefiles that are just containers for the classes should be thrown away. If one wants to continue developing a project, give him the class he/she wants to edit into VS, a "source file" is not needed for editing. The same is valid for new classes. Let the class be created in VS, added to the source control system e. g. TFS and give it a version. No need to create a source file. Give me a diagram of my classes, some kind of UML diagram and visualize the existing classes and any changes/merges on them. Give me a hint about what client classes that call methods on a class that has changed methods do not match anymore regarding the method signature. Track the dependancies. Thank you.

Add a method called HasAccess to the FileSystemInfo class. This method would tell you whether a user has permisssions to a file or directory without needing to try and catch exceptions. By default this would check that the current user has PathDiscovery permissions, but these parameters could also be specified.

An example use case: Explorer windows in applications.
By allowing coders access to this information, they can specify a different icon for non-accessible files/folders, users are then less likely to get surprises at runtime. I admit permissions may change at runtime so exception handling is still required, but showing the users up front means that they don't get a bunch of error messages at runtime (or have the program simply ignore the errors and deliver unexpected results).

using System.Security.Permissions;
using System.Security.Principal;

bool HasAccess(WindowsIdentity user, permission)
{
throw new NotImplementedException();//not currently possible according to what I've found so far
}
bool HasAccess(WindowsIdentity user) {return HasAccess(user,FileIOPermissionAccess.PathDiscovery);}
bool HasAccess(FileIOPermissionAccess permission) {return HasAccess(WindowsIdentity.GetCurrent(), permission);}
bool HasAccess() {return HasAccess(WindowsIdentity.GetCurrent());}