Resize Performance vs swift

[RazgrizHsu]

I would like to ask everyone,
I want to shrink 200 pictures and reduce the size,
but it takes nearly 4 minutes to process these pictures, is this normal?

Because if I do the same thing in swift it takes only 12 seconds

here is the code..

#![allow(non_snake_case)]

use std::fs::File;
use std::path::PathBuf;

use image::imageops::FilterType;
use image::{ImageFormat, ImageOutputFormat};

use image::io::Reader as ir;


use std::sync::{Arc, Mutex};
use std::sync::atomic::{AtomicBool, Ordering};
use std::thread::sleep;
use std::time::Duration;
use concurrent_queue::ConcurrentQueue;


pub async fn test_multi_resize()
{
	let pathDir = "/Volumes/tmp/tmp/try";
	let pathOut = "/Volumes/tmp/tmp/ok";


	let files = std::fs::read_dir( &pathDir ).expect("cannot load dir");

	let mut paths: Vec<PathBuf> = vec![];

	for path in files
	{
		let path = path.expect("no").path();
		if !path.is_dir()
		{
			paths.push( path.to_path_buf() );
		}
	}


	let q: ConcurrentQueue<PathBuf> = ConcurrentQueue::unbounded();

	let mut tasks = Vec::new();
	let rtm = tokio::runtime::Runtime::new().unwrap();

	let end = AtomicBool::new(false);

	let stopAll = Arc::new(end);

	let queue = Arc::new(q);

	for _ in 0..10
	{
		let stop = stopAll.clone();
		let q = queue.clone();

		tasks.push( rtm.spawn(async move
		{
			while !stop.load( Ordering::Relaxed )
			{
				if let Ok(p) = q.pop()
				{
					let img = match image::open( &p )
					{
						Ok(img) => img,
						Err(ex) =>
						{
							println!( "err: {}, {ex:?}", &p.to_str().unwrap_or( "---" ) );
							return;
						},
					};

					let resized_img = img.resize(1680, 1280, FilterType::Nearest);

					let op = format!( "/Volumes/tmp/tmp/ok/{}", p.file_name().unwrap().to_str().unwrap() );
					let mut out_file = File::create( &op ).unwrap();
					resized_img.write_to( &mut out_file, ImageOutputFormat::Jpeg(60) ).unwrap();
				}
			}
		}));
	}

	for p in paths
	{
		queue.push(p.to_owned()).unwrap();
	}

	// wait all
	while queue.len() > 0
	{
		sleep( Duration::from_secs_f64( 1.0 ) );
	}


	stopAll.swap(true, Ordering::Relaxed );

	for t in tasks { tokio::join!( t ); }

	rtm.shutdown_background();
}

[HeroicKatora]

Please use discussions or other forums for general support. It's not appropriate in the issue tracker unless it can lead to some action by a current of future contributor. But there needs to be insight into a comparative technique that Swift is using to explain the difference for this. You haven't posted Swift code so it could be anything from better implementationt to GPU acceleration—which is out-of-scope—to Apple using other special hardware that we don't have direct access to.

On the face of it, the block above is not using async correctly. Spawning tasks will only make asynchronous code concurrent but all your tasks are synchronous functions (as noted by the lack of await). So everything still happens synchronously with the additional overhead of the task scheduler.

[fintelia]

FYI: there's a "convert to discussion" link hidden on the right sidebar of issues

[RazgrizHsu]

I can't find a discussion forum about this library elsewhere,
perhaps you could tell me the link, thank you.

And I found that the bottleneck of this code is in

let mut out_file = File::create( &op ).unwrap();
resized_img.write_to( &mut out_file, ImageOutputFormat::Jpeg(60) ).unwrap();

If change to

resized_img.save_with_format( &op, ImageFormat::Jpeg ).unwrap();

The total time will reduce to 30s..

Is it my mistake in using it, or does reducing the quality take that much time?
Please give me some guidance, I would be greatly appreciative.

[HeroicKatora]

The largest difference is then most likely the jpeg encoder. The one used by image is found here; it could be replaced by something else if that's the bottle neck. Changing the quality won't behave exactly predictable with regards to encoding time. The parameter controls file size / compression more than the time itself.