(account deleted)GC Allocator Summary
FoldUnfold Table of Contents C++ Memory Management Innovation: GC Allocator A Word File Writer Rope based on GC Allocator STL Containers based on GC Allocator The Fastest Word File Writer C++ Memory Management Innovation: GC Allocator Link: http://www.codeproject.com/KB/cpp/gc-allocator.aspx Highlights: The tiniest, fastest allocator and easy to use. And it became a boost sandbox library on 2008-04-29. I'm preparing for a peer review. It is easy to use: Like GC languages (eg. Java, C#, etc), it is no need to delete allocated objects by using GC Allocator. It is faster than all allocators you ever seen: For the detail information about the comparison, see Allocators Performance Comparison . Why GC Allocator is so fast? It benefits from: Its good allocation algorithm. No...
Dive into GC Allocator
A Proposal to Cancel Overriding the DEFAULT operator new/delete
FoldUnfold Table of Contents Motivation Impact on the Standard Proposed Text Motivation I don't think we need to override the DEFAULT operator new/delete. This makes your code doesn't work well together 3rdparty code (if it also overrides them). Why overriding the DEFAULT operator new/delete is bad? Allowing to override the DEFAULT operator new/delete means the DEFAULT operator new/delete are special operators. When we have more than one implementations of an operator, the compiler/linker will report a redefining error. However, it allows there are two implementations of the DEFAULT operator new/delete (one of them is implemented as default). It sounds good. But, This gives a hint that there may have many implementations of the DEFAULT operator new/delete. When this happens, the...
这些广告的受益者并非本人，而是 Wikidot。我个人从不掩饰对 Wikidot 的喜爱，它给了我想要的东西，我们为它赚点广告费，我觉得这是很正常事情。Wikidot 也是很有原则的一家公司，她对客户的尊重是我喜爱她的另一个重要原因，要想进入本站而不出现广告很简单，注册个 Wikidot 账号，在浏览本站的时候保持登录状态就好了，你会看到一个很干净的界面。
许哥，能说一下，go和erlang的一些比较吗？
哪一个更适合大规模的实际应用？
多谢
如果你不考虑具体的使用场景，建议选择 golang。erlang 的适用范围相对狭窄。
两者目前都重服务端，所以客户端开发来说，都不是特别适合，如果非要用，建议用 golang。
服务端开发，如果团队比较小，喜欢函数式编程，而且网络模块偏重 io，逻辑不复杂，用 erlang 可以获得比 go 更好的性能，目前 go 语言在性能上还没做过非常大力度的优化。其他情况我建议用 golang。
我用erlang做过手机银行的服务端，效果还是不错的
多谢许哥这么详细的说明，这样就清楚怎么选择了，多谢
在执行单元的公平调度方面，还是请指点下：
比如我要做一个管理大量设备(成千上万)的程序，需要即时监控设备状态，erlang进程的公平调度性是适合这个场景的，golang在这点上机制如何？
许哥您好:
看到您编写的winx, 我有一个问题请教, 为什么MFC的消息映射要提供_AFXDLL和非_AFXDLL两个implementation, 比如
#ifdef _AFXDLL
#define DECLARE_MESSAGE_MAP() private: static const AFX_MSGMAP_ENTRY _messageEntries[]; protected: static AFX_DATA const AFX_MSGMAP messageMap; static const AFX_MSGMAP* PASCAL _GetBaseMessageMap(); virtual const AFX_MSGMAP* GetMessageMap() const;
#else
#define DECLARE_MESSAGE_MAP() private: static const AFX_MSGMAP_ENTRY _messageEntries[]; protected: static AFX_DATA const AFX_MSGMAP messageMap; virtual const AFX_MSGMAP* GetMessageMap() const; #endif
为什么直接用非_AFXDLL的版本的不行? 非要用一个函数_GetBaseMessageMap()去取基类的messageMap?
许哥您好，请教一个问题：
golang http.ResponseWriter 的Write()方法，服务的QPS由3万降到7000。附上我的测试代码和boom测试结果：
现在我测试到的情况是这样的，如果我只填写http的header，那么服务端的处理速度很高，单纯测试（没有业务逻辑），QPS能达到3万，但是如果我添加payload，那么QPS就只能达到不足8000了，只有6000的样子。这个落差太大了，我尝试直接使用http.ResponseWriter 接口中的Write方法写入一个［50］Byte，效果一样。根据我的测试和你们的分析，应该是IO的问题，不过这个也太夸张了。
func handleHeader(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "0") }
func handlePayload50(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "50") w.Write(make([]byte, 50)) }
func handlePayload128(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "128") w.Write(make([]byte, 128)) }
func handlePayload1024(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "1024") w.Write(make([]byte, 1024)) }
func main() { runtime.GOMAXPROCS(runtime.NumCPU()) http.HandleFunc("/header", handleHeader) http.HandleFunc("/payload50", handlePayload50) http.HandleFunc("/payload128", handlePayload128) http.HandleFunc("/payload1024", handlePayload1024) host := fmt.Sprintf("%s:%d", "0.0.0.0", 5001) http.ListenAndServe(host, nil) }
and the boom test result: ./boom -c 1000 -n 500000 -cpus 12 XXXXXX/header 500000 / 500000 Boooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 %
Summary: Total: 12.8799 secs. Slowest: 3.2799 secs. Fastest: 0.0018 secs. Average: 0.0239 secs. Requests/sec: 38810.4907
Status code distribution: [200] 499875 responses
Response time histogram: 0.002 [1] | 0.330 [499306] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.657 [0] | 0.985 [0] | 1.313 [312] | 1.641 [0] | 1.969 [0] | 2.297 [0] | 2.624 [0] | 2.952 [0] | 3.280 [256] |
Latency distribution: 10% in 0.0125 secs. 25% in 0.0172 secs. 50% in 0.0216 secs. 75% in 0.0257 secs. 90% in 0.0295 secs. 95% in 0.0327 secs. 99% in 0.0549 secs.
./boom -c 500 -n 500000 -cpus 12 XXXXXX／payload128 500000 / 500000 Boooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 %
Summary: Total: 62.5205 secs. Slowest: 3.0714 secs. Fastest: 0.0112 secs. Average: 0.0601 secs. Requests/sec: 7997.1501 Total Data Received: 63998208 bytes. Response Size per Request: 128 bytes.
Status code distribution: [200] 499986 responses
Response time histogram: 0.011 [1] | 0.317 [495652] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.623 [0] | 0.929 [0] | 1.235 [4092] | 1.541 [0] | 1.847 [0] | 2.153 [0] | 2.459 [0] | 2.765 [0] | 3.071 [241] |
Latency distribution: 10% in 0.0405 secs. 25% in 0.0436 secs. 50% in 0.0481 secs. 75% in 0.0546 secs. 90% in 0.0629 secs. 95% in 0.0731 secs. 99% in 0.1054 secs.
许哥：go如何通过一个字串动态创建对象？
比如java里面，有myObject = class.forName("my.com.myObject");
假设有一个mysql库字串是 "github/mysql"，我如何像java一样动态得到这个mysql的接口或结构？比如假设可以 sqltest=newObject("github/mysql")?
Post preview:
Close preview