嘿，针对你的问题我来拆解说明：

一、Telerik、DevExpress Win Form控件的核心开发语言 #

• Telerik UI for WinForms：主力开发语言是C#，毕竟WinForm本身基于.NET生态，C#和框架的契合度最高。不过在一些对性能要求极高的模块（比如底层渲染、大数据量计算），会用C++来做底层优化，平衡.NET的开发效率和原生性能。
• DevExpress WinForms：同样以C#作为主要开发语言，少数涉及Windows原生交互、高频绘图的部分会用C++/CLI或者纯C++实现，既要兼容.NET的开发体验，又要保证复杂场景下的运行流畅度。

二、自研高性能Data Grid的关键优化方向 #

你之前做自定义控件遇到分组、排序后卡顿的问题，大多是数据处理和UI渲染的效率没跟上，给你几个实用的优化思路：

• 启用数据虚拟化：别一次性把所有数据都塞给UI，只渲染当前窗口能看到的行。可以借助WinForm的VirtualMode模式，手动控制行的加载和绘制逻辑，避免大量数据占用内存和拖慢渲染速度。
• 异步处理耗时操作：分组、排序、筛选这些操作如果数据量大，一定要放到后台线程去做，别阻塞UI线程。比如用Task.Run()把数据计算逻辑剥离出来，计算完成后再通过Control.Invoke()安全更新UI。
• 优化渲染逻辑：开启控件的DoubleBuffered属性减少闪烁，提前缓存绘制需要的样式（比如分组头背景、小计行字体），避免在Paint事件里做重复计算。尽量使用GDI+的高效绘制方法，少用复杂的控件嵌套。
• 优化数据结构：针对分组、排序需求，提前用合适的数据结构维护索引。比如分组时用Dictionary<TKey, List<TData>>把数据按分组键存好，后续直接读取分组后的集合，不用每次都遍历全量数据。
• 基于原生控件扩展：如果不是必须从零造轮子，建议基于原生DataGridView做扩展，而不是完全自研。原生控件已经做了很多底层优化，在它之上添加分组、小计、筛选功能，能省很多性能优化的精力。比如可以继承DataGridView，重写OnRowPostPaint来绘制小计行，或者自定义列类型实现筛选控件。

三、文本行&行间小计的实现思路 #

• 自定义文本行：可以给行添加一个类型标记（比如RowType.Text），在渲染时判断标记，用独立的样式绘制，并且让这类行跳过数据绑定、编辑等逻辑。
• 行间小计：在分组计算阶段，提前在每组数据的末尾插入小计行的数据源（或者单独维护小计行的集合），渲染时和普通数据行一起处理，注意区分小计行的交互逻辑（比如设置为不可编辑、高亮样式）。

内容的提问来源于stack exchange，提问作者Rehmak Natiq