C# 哪个需要更多内存，字符串值还是长值？

我有一个连接到WCF服务的客户端应用程序，我从服务器获取文件大小作为

long

值，然后在客户端将其转换为

string

，因此它看起来像ex:

52.21MB

每次用户更改当前目录路径时，应用程序都会获取太多文件大小

我的问题：我应该从WCF服务应用程序将值转换为

string

格式，然后将其作为

string

返回给客户端，还是应该将大小作为

long

值返回，让客户端将其转换为

string

格式

换句话说，哪个值在内存中占用更多字节：

long size = 55050240;
string size = "52.5 MB"; 

long large_size = 56371445760;
string large_size = "52.5 GB";

更新： 我使用此方法将长值转换为字符串格式：

private string ConvertUnit(long source)
    {
        const int byteConversion = 1024;
        double bytes = Convert.ToDouble(source);

        if (bytes >= Math.Pow(byteConversion, 3)) //GB Range
        {
            return string.Concat(Math.Round(bytes / Math.Pow(byteConversion, 3), 2), " GB");
        }
        else if (bytes >= Math.Pow(byteConversion, 2)) //MB Range
        {
            return string.Concat(Math.Round(bytes / Math.Pow(byteConversion, 2), 2), " MB");
        }
        else if (bytes >= byteConversion) //KB Range
        {
            return string.Concat(Math.Round(bytes / byteConversion, 2), " KB");
        }
        else //Bytes
        {
            return string.Concat(bytes, " Bytes");
        }
    }

---

简短问题：哪个需要更多内存，

字符串

值还是

长

值？

让服务层输出格式化的值是一个非常糟糕的主意。如果需求发生变化，客户端应用程序UI需要以字节为单位输出，而不是使用GB后缀，会发生什么情况？e、 g.

56371445760

？这需要客户端应用程序解析然后重新格式化服务器发送的数据

此外，确定存储单个变量所需的内存也很容易。不那么容易的是计算出对应用程序的总体影响。不同的类型在代码中的处理方式会有所不同，因此较小的变量可能会带来更大的成本。

“哪个需要更多的内存、字符串值或长值？”

C#中的字符串是Unicode字符（每个字符有两个字节）+指向该地址的指针（最小4个字节，x64.NET应用程序上为8个字节）

长度为8字节。一旦在x86上超过2个字符，或在x64上超过任何字符，将占用更多内存

但是字符串是不可变的，如果发送大量大小相同的文件，字符串将消耗更少的内存

对于实际问题，应该使用long来真正表示底层对象

编辑：

---

更正为考虑字符串的指针大小。

一个.NET字符串是一个UTF-16代码单元数组，每个单元长2字节。因此，“52.5MB”将占用7*2=14字节，甚至不考虑对字符串的引用（4或8字节，取决于进程的“比特度”）和辅助字段，如字符串长度。

long

是8个字节，因此很明显字符串“更胖”

此外，您的示例并不传达相同的信息（字符串中的“精度”正在降低），因此这就像比较苹果和桔子一样

即使编码在SOAP消息中，long也应该比string更紧凑

---

出于所有这些原因，我选择了

long

这并不是一个需要更多字节的问题。消费者需要什么类型的值？@MitchWheat它是一个文件浏览器，一个列表视图显示带有图标的文件和文件夹，一个子项以字符串格式显示大小。meh；零长度字符串仍然需要一个引用-在x64上是8字节。然后是对象标题。。。。绳子总是比较大。