内存映射文件与命名管道的速度谁快

vegascsu 2012-06-21 10:32:25

我有两个进程，需要进行进程间通信，采用请求/响应的机制。
由于请求/响应的次数，1秒内估计有1万次，现在用的是命名管道，发现速度不行。当然这个时间也跟另一个进程的数据处理时间有关。请问有没有更快的方式，比如内存映射文件是不是更快呢。

...全文

534 11 打赏收藏举报

写回复

用AI写文章

11 条回复

切换为时间正序

请发表友善的回复…

发表回复

pathuang68 2012-06-21

打赏
举报

[Quote=引用 7 楼的回复:]

响应方确实具有多个线程，估计最大时会有60个线程，我现在是直接用CreateThread来创建线程的。请问这种方法，是不是较慢。是不是你说的线程池会快一些呢。
另外消息队列你是指通信上用消息队列吗？
我试了一下，主要时间浪费在响应方的数据处理上，通信时间很少，数据处理上时间的增加，主要是加入了线程同步，我用的是临界区。不用线程同步，程序就会异常，请问有没有好的解决方案

引用 3 楼……
[/Quote]

1. 就用线程池吧。线程频繁的创建和销毁会需要很多时间，线程池可以避免这个消耗。
2. 你开了60个线程是否太多了？由于线程太多做造成线程同步的消耗也不容小视，还有你的机器上估计也没有60个CPU内核吧？这样密集的运算开再多的线程意义也不大，反而会降低处理速度。

赵4老师 2012-06-21

打赏
举报

共享内存＋锁

vegascsu 2012-06-21

打赏
举报

响应方确实具有多个线程，估计最大时会有60个线程，我现在是直接用CreateThread来创建线程的。请问这种方法，是不是较慢。是不是你说的线程池会快一些呢。
另外消息队列你是指通信上用消息队列吗？
我试了一下，主要时间浪费在响应方的数据处理上，通信时间很少，数据处理上时间的增加，主要是加入了线程同步，我用的是临界区。不用线程同步，程序就会异常，请问有没有好的解决方案

[Quote=引用 3 楼的回复:]

并发处理看行不行啊，
响应方用线程池来处理~~
看消息队列行不？
[/Quote]

vegascsu 2012-06-21

打赏
举报

[Quote=引用 5 楼的回复:]

那用共享内存吧, 申请个500M的, 里面建个环形队列, 做一个进程共享mutex+cond, 做lock+cond_wait+cond_brodcast支持多进程并发写多进程并发读，保证无死锁。
[/Quote]

我测了一下，好像确实不是通信的时间问题，主要是我内部数据处理的时间造成的。
由于内部数据处理所在的那个进程，有多个线程，我用的是临界区的线程同步方法，所以造成时间较慢。
你说的这种方法，有没有详细的介绍，或者推荐一下资料看看呀

qq120848369 2012-06-21

打赏
举报

那用共享内存吧, 申请个500M的, 里面建个环形队列, 做一个进程共享mutex+cond, 做lock+cond_wait+cond_brodcast支持多进程并发写多进程并发读，保证无死锁。

pathuang68 2012-06-21

打赏
举报

应该不会更快。内存映射文件通常的目的：用操作内存的方式，操作磁盘文件的，尤其是是针对文件比较大的时候。

直接用共享内存试试吧，如果还不行估计常规的办法就木有了。

jody_go 2012-06-21

打赏
举报

并发处理看行不行啊，
响应方用线程池来处理~~
看消息队列行不？

luciferisnotsatan 2012-06-21

打赏
举报

自己测一下不就清楚了

龙哥依旧 2012-06-21

打赏
举报

just try it !

jackyjkchen 2012-06-21

打赏
举报

命名管道走网络协议栈，速度应该慢些

内存映射擅长随机操作文件，能大大降低操作复杂度，顺序操作的话（不用seek跳来跳去），普通I/O也不麻烦，只是相当于多一层缓冲，效率略低

线程是太多了，尽量用线程池

qq120848369 2012-06-21

打赏
举报

[Quote=引用 7 楼的回复:]

响应方确实具有多个线程，估计最大时会有60个线程，我现在是直接用CreateThread来创建线程的。请问这种方法，是不是较慢。是不是你说的线程池会快一些呢。
另外消息队列你是指通信上用消息队列吗？
我试了一下，主要时间浪费在响应方的数据处理上，通信时间很少，数据处理上时间的增加，主要是加入了线程同步，我用的是临界区。不用线程同步，程序就会异常，请问有没有好的解决方案

引用 3 楼……
[/Quote]

响应速度慢造成的队列阻塞必须多线程/多进程并发, 没什么好考虑的.

如果你考虑内存已经承载不了那么大的排队阻塞了, 可以考虑使用开源消息队列, 保证不会因为内存耗尽崩掉, 并且可以持久化避免数据丢失.

在多任务和多进程的操作系统中，进程通常是相互独立的，各自拥有独立的内存地址空间。然而，进程之间经常需要传递数据和信息，以实现某些功能或协调任务。因此，操作系统提供了一系列进程间通信的机制。

在现代操作系统中，进程间通信（IPC）是实现多任务协作的关键技术。本指南将通过IPC-Bench项目提供的权威性能数据，深入对比四种主流IPC机制——共享内存（Shared Memory）、内存映射文件（mmap）、管道（Pipe）和FIFO（命名管道）的性能表现，帮助开发者为不同应用场景选择最优通信方案。 ## 核心IPC机制性能概览 🚀 IPC-Bench项目（[GitHub 加速计划

进程间通信(IPC)是操作系统核心机制，用于实现协同工作的进程数据交换。命名管道(Named Pipe)通过文件系统接口提供流式通信，适合顺序数据处理场景；共享内存(Shared Memory)则通过内存映射实现零拷贝传输，提供接近物理内存带宽的性能。这两种IPC技术在现代分布式系统和高性能计算中广泛应用，特别是在需要低延迟、高吞吐的微服务架构和并行计算场景中。命名管道以其简单性著称，常用于日志收集和命令行工具链；而共享内存凭借其卓越性能，成为金融交易系统和实时数据处理的首选方案。理解它们的同步机制(如信号

当你面对10GB级别的数据库备份、日志文件或传感器采集数据时，是否经历过： - 使用`FileStream`读取导致内存溢出异常 - 分块处理逻辑复杂且IO瓶颈明显 - 跨进程共享数据时的管道/套接字性能损耗 **本文将彻底解决这些痛点**，通过.NET内存映射文件（Memory-Mapped Files）技术，让你无需复杂架构即可实现： - 大文件随机访问性能提升80%+ - 内存占用降低90...