字符串变量和char列的长度

自从。NET字符串不是以null结尾的,你必须非常聪明,才能在每个字符串中实际使用完美数量的字符。

String message = "hello world!!!!!"; // Exactly 16 chars

此外,只有当您的实现使用“malloc”执行内存分配时,两次调整字符串大小的能力才重要。这是一种内存分配策略,它说“如果我的单个内存位和内存块都有两种大小的能力,那么它们将更好地放入堆中,浪费的空间更少”。

但是。NET不使用malloc来分配内存。相反,所有堆内存都是通过递增堆指针来分配的。当GC稍后释放内存时,它将执行堆压缩,这样所有新内存都来自末尾,它永远不需要在碎片堆中找到一小块内存。

对于数据库中的列:注意SQL的8kb数据页。行越小,每个数据页上可以容纳的行就越多。每个数据页中可以容纳的行越多,读取这些行的速度就越快(页面越少,IO就越少)。这适用于表和索引。

以下是一些更多信息 Wikipedia .

不。你会如何处理你没有使用的字符串块,因为它只是填充。与试图对齐字符串可能带来的任何节省相比,这种浪费的成本将是巨大的。无论如何,这样的长度是否会有任何好处,这是非常值得怀疑的。

C#中的字符串。Net是不可变的,因此在构造字符串时没有必要(或任何方式)预先分配空间来容纳更多字符。如果你向字符串追加一个新字符串,它会创建新的空间来容纳整个新字符串,而不会重新分配。对于SQL列,如果您事先知道(char(N))或使用不同的字符数据(varchar(N),则应将其设置为字符串的确切长度,并选择N作为合适的最大值。我看不出保持2的幂有什么意义——当你创建varchar列时,ExpressRoute默认为50,所以微软显然也没有。

预分配可能会产生影响的一个地方是StringBuilder或预分配集合的大小。同样,它的大小应该以不必调整大小为目标,但如果知道的话,应该接近其实际用途。如果不知道,那么要么跳过初始尺寸,要么使其足够大以容纳大多数箱子。

这是一个优化可能没有那么有益的领域。我会根据需要定义长度,然后在需要时再回来优化长度。我认为你会发现默认处理字符串长度就足够了。

不是。两种规模优化的力量来自数据库时代的黎明,与数据在磁盘和内存中的对齐方式有关。今天,这是一种没有优势的退化行为。