写点什么

ASP.NET Core 改进了.NET Framework 中的字符串处理

  • 2017-05-15
  • 本文字数:1833 字

    阅读完需:约 6 分钟

显然 Microsoft 开发人员和管理人员并没有表达清楚,事实上 ASP.NET Core 2.0 将会得到整个.NET Framework 的支持。当前的更改只实现了在 ASP.NET 上提供.NET Core,这是为了便于开发而采取的一个临时步骤。对此,在 ASP.NET Core 预览发行声明中给出了如下的解释:

在发布 ASP.NET Core 2.0 预览版时,仅提供了对.NET Core 2.0 SDK 的支持。我们的目标是在.NET Standard 2.0 中发布 ASP.NET Core 2.0,使应用可运行在.NET Core、Mono 和.NET Framework 上。团队正致力于在 Build 大会之前解决最后一些问题,最突出的问题是在 ASP.NET Core 2.0 预览版中使用了.NET Standard 2.0 之外的 API,这妨碍了在.NET Framework 上的运行。由于这些问题,我们限制了 Preview 1 版本对.NET Core 的支持,以免对开发人员在.NET Framework 上将 ASP.NET Core 1.x 应用升级到 ASP.NET Core 2 预览版时造成破坏。

在 Register 的一次采访中, Miguel de Icaza 确认了 Microsoft 对.NET Framework 的承诺

我要对此做出澄清。我感到十分遗憾的是,即将推出的.NET Core 2.0 是我们专为 Build 大会准备,它只是一个预览版,因为我们发现其中存在一系列在.NET Framework 上无法很快得到解决的问题。因此,我们推出的软件包仅支持在.NET Core 2.0 上运行 ASP.NET Core 2.0。我们将会修复这个问题,.NET Core 2.0 终将运行在.NET Framework 上。

即便是临时性更改,一个依然需要解决的问题是:要想进一步改进 ASP.NET 的性能,需要提供更好的字符串处理库。

内存分配上的考虑

在.NET 中,几乎所有的字符串处理方法都要做内存分配,该问题长期以来一直为人所诟病。在解析 JSON、XML 等格式时,substring方法常会产生成百上千的微小字符串分配。这不仅耗费了大量时间生成拷贝,而且对垃圾回收造成了很大的压力。这并非应用开发人员所能掌控的。

这种做法有其合理性。与.NET 一样,在 Java 中字符串也是不可变的。而 Java 自带的substring方法并不分配新的字符串,它创建一个指向原始字符串的指针。虽然 Java 的substring方法无需分配内存,但是存在着内存泄漏的风险。一个字符串 substring方法可以保留 5MB 字符串不被垃圾回收(这个问题相当恶劣,因此在 Java 1.7u6 版中做了更改,substring方法做内存分配)。

在“ Span建议”中,开发人员可以选择使用两种不同的substring方法,即分配内存的方法和不做内存分配的方法。ASP.NET Core 所使用的解析库也可以被覆写,在内部使用不分配内存的substring方法。但在解析操作的最后阶段,需要确保释放所有 Span的实例。

这一更改还需要重新实现更高效的基本类型解析方法,例如 Int32.Parse 和 Inta32.TryParse 等。理想情况下,这些方法将会加入到基类库(BCL,Base Class Library)中,而不是以单独库的方式提供。这就回到了.NET Framework、Standard 和 Core 的对比问题上。

毫无疑问,可以加快对.NET Core 的更改过程。除了操作系统特定的功能,新特性将做优先更改。否则,只有得到所有.NET/Mono 的各种实体(incarnation)支持的新特性,才会出现在.NET Standard 中。虽然从理论上讲,这些实体也归属于 Microsoft 的,但是新特性的添加依然会是一个冗长的过程。

因此,在开发 ASP.NET Core 的过程中,基于 ASP.NET 进行构建是合乎情理的。这使得新的 API 在提交标准化前,得到真实用例的精炼。

默认编码上的考虑

并非所有开发人员都了解,在.NET 内部使用的是 UTF16 字符串。除了实现文件或网络 I/O 处理之外,对于大部分用例,开发人员都无需考虑编码问题。

Web 应用主要基于 UTF8 编码。同样,在处理大部分用例时,服务器端开发人员也无需考虑编码问题。只需确保无论使用何种内部格式,最终都会转换为 UTF8 编码。

当需考虑性能时,这种做法就存在问题。所有的 Web 请求最初都是以 UTF8 编码的,需要在被.NET 理解前转化为 UTF16 编码。反之,所有来自.NET 服务器的响应,需要由 UTF16 编码转化为 UTF8 编码。

现在已有一些建议方法,意在消除这种转换的必要。一种做法创建了 Utf8String 类并匹配字符串处理库,之后就可以新建直接操作类的解析库。这一做法是完全“明确征得同意”(Opt In)的,因此风险很低。

更全面的建议是由 Matt Warren 提出的,称为“紧凑字符串(Compact String)实现”。该建议受到了 OpenJDK 中类似建议的启发,它会在字符串中添加一个类型字段,用于指示所使用的编码。这是一种更大程度上的更改,对 Span存在一些负面影响。

查看英文原文: What ASP.NET Core May Bring to the .NET Framework’s String Handling

2017-05-15 19:001560
用户头像

发布了 227 篇内容, 共 68.4 次阅读, 收获喜欢 26 次。

关注

评论

发布
暂无评论
发现更多内容

什么是MircoPython?

华为云开发者联盟

Python 编程语言 物联网 MicroPython 嵌入式应用

什么是高效,什么是好的企业文化

Ryan Zheng

DistSQL:像数据库一样使用 Apache ShardingSphere

SphereEx

智汇华云|安超云套件Archer Cloudsuite为“信创强国”筑基

华云数据

从零开始学习3D可视化之数据对接(1)

ThingJS数字孪生引擎

大前端 可视化 3D 3D可视化 数字孪生

一文搞懂一致性hash的原理和实现

万俊峰Kevin

微服务 hash Go 语言

PNFile功能介绍

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

PNFind文件搜索器

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

打造全景5G专网运营能力,差异化赋能行业生态

鲸品堂

场景

比redis-rdb-tools快10倍的rdb分析工具

BUG侦探

redis bigkey rdb分析

产业区块链迎来新纪元,基础设施建设成核心命题

旺链科技

区块链 产业 基础设施建设

容器安全检查列表

greatersecurity

容器 云原生 DevSecOps

PNTree 目录结构树

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

PNEdit 百科

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

天津大学教授站上 WICC2021 “讲坛” 将分享边缘计算新研究

融云 RongCloud

PNComp目录比较器

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

JVM优化过头了,直接把异常信息优化没了?

why技术

Java JVM

百度内容风控是怎样在秒级之内完成词表匹配

百度Geek说

百度 内容审核

PNFile 百科

Geek_6bf591

PNFile入门指南

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

手写希尔排序算法

实力程序员

编程 程序员 C语言 排序算法

Go语言,你必须掌握的--高效并发模式!

微客鸟窝

Go 语言

智慧能源:清洁低碳环保新能源,沙漠光伏与光热发电站 3D 可视化

一只数据鲸鱼

数据可视化 智慧能源 光伏发电 沙漠光伏

PNEdit文本编辑器

Geek_6bf591

vim emacs vscode UltraEdit 文本编辑器

[翻译] 关于学习 InnoDB:InnoDB 核心之旅

keaper

MySQL 数据库 后端 服务端 innodb

为什么互动直播可以发展如此迅速?

anyRTC开发者

在线教育 视频直播 直播连麦 互动直播 电商直播

用10个真实案列带你掌握MySQL调优

北游学Java

Java MySQL 性能调优

ASP.NET Core改进了.NET Framework中的字符串处理_.NET_Jonathan Allen_InfoQ精选文章