Don't use Span.Content.

[NTaylorMullen]

Today we use Span.Content in several locations where we don't need to during parse and code gen time. Instead we should be utilizing the Symbols that are available to us to prevent additional allocations.

[henkmollema]

Off-topic: but I was just wondering what profiling tool you are using and how do you measure just the code of the library and not DNX code as well.

[NTaylorMullen]

I'm using dotMemory. It's quite nice because you can have DNX boot your application and then you choose when to start collecting a profile. That way you only start collecting once your app is up and running.

[Eilon]

@NTaylorMullen need an update on this because it's been stale. Have we seen perf issues here that we need to investigate for 1.0.0? If not, I'll move this out.

[NTaylorMullen]

@ToddGrun are there perf issues associated with the amount of strings we've been allocating on the Visual Studio Razor editor side of things? I haven't heard anything so I'm tempted to say post 1.0.0.

[Eilon]

@NTaylorMullen can you email @ToddGrun about this? Might be easiest.

In the meantime, moving out.

[ToddGrun]

@Eilon We haven't noticed any allocation issues, but we haven't done allocation profiling in razor scenarios.

[Eilon]

@ToddGrun ok thanks!

[NTaylorMullen]

In order to accomplish this change we'd need to break API compatibility. This should be pushed out until we're able to do that.

[NTaylorMullen]

Ping to push out to a milestone that enables us to break API compatibility.

[Eilon]

Moved to 2.x