The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Postlog to the Log Flog (Eating Crow)

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Postlog to the Log Flog (Eating Crow) Posted: Dec 14, 2005 11:00 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Postlog to the Log Flog (Eating Crow)
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Travis Griggs - Blog

Advertisement

Troy and I were rehashing some of yesterdays long blog. It seemed prudent for a redux.

First and foremost. Halfway through writing this blog, I discovered an error. Anyone surprised? But I learn more and more. The C flush() function is analagous to the VisualWorks flush method. The man page points out: "Note that fflush() only flushes the user space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, e.g. with sync(2) or fsync(2)." Like the man page, you have to scroll to the bottom of the MSDN Write() reference for C#'s StreamWriter and follow a link or two to discover that it is the same. I can't actually find a method that allows you to force a sync, but you can set the StreamWriter to "AutoSync" or something like that. IMO, any "log" should "commit" each entry to disk. So both of Troy's versions (Smalltalk and C#) were, uh, flawed (sorry Troy, I gotta pass some of the buck for my bad journalism here, I'm running low on my daily allotment of hubris).

From a "logging" perspective, this whole premise is a waste of time. If you've got an application that needs to generate 85 MB of superfluous and synced logging in under 15 seconds, you have much larger issues. Number one, it's not gonna happen. Under any language. Number two, at that rate, you're gonna fill a disk pretty fast.

So how does VW IO stack up now? The workspace script:

fd := IOAccessor defaultForFiles openFileWriteOnly: 'log'.
bytes := ByteArray new: 8192.
(Time millisecondsToRun: [10000 timesRepeat: [fd writeFrom: bytes startingAt: 1 forSure: 8192]]) out.
fd close 
can generate an 80+MB file in 320 ms. A C version which does the analog, does it in 306 ms. So not much speed difference. Interestingly, placing a commit in the loop, and an fsync() at the same point in the C code, produces times of 21 seconds for VW and 26 seconds for the C version.

The final conclusion is that like any software I write, you should probably wait for the .1 or .2 release of any of my blogs. :(

Blog categories are like code comments. They lie.

Read: Postlog to the Log Flog (Eating Crow)

Topic: Making the world worse, one step at a time Previous Topic   Next Topic Topic: Just use Play-Doh

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use